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I.  Introduction 

The  Graphics  and  Video  Laboratory  of  the  Department  of  Computer  Science  at  the 
Naval  Postgraduate  School  permits  the  researcher  to  create  three-dimensional  visual 
simulations  from  digital  terrain  data  [Ref.  1].  Specialized  graphics  hardware  allows  the 
display  of  such  simulations  in  near-real  time.  The  goal  of  a  good  part  of  the  work  in  the 
lab  is  the  creation  of  a  movie-like  view  of  movement  over  and  on  terrain,  with 
increasingly  complex  movement  animation  models.  Such  projects  have  strained  the 
equipment's  capabilities.  One  method  of  increasing  available  computing  power  is  to 
harness  multiple  heterogeneous  machines  together  in  some  distributed  computing 
organization.  It  requires  communication  between  the  various  machines,  as  well  as 
carefully  matching  each  machine's  capabilities  to  its  assigned  tasks. 

A.      PROBLEM 

Rapid  turnover  of  inexperienced  students  at  the  Naval  Postgraduate  School  makes 
the  creation  of  complex  simulations  difficult  to  manage.  The  learning  curve  becomes 
steeper  as  the  lab's  capabilities  increase.  One  of  the  areas  of  difficulty  has  been  inter- 
computer communications.  So  much  time  has  been  spent  on  designing,  coding,  and 
debugging  communication  software,  little  has  been  left  for  the  original  research.  We  set 
out  to  provide  an  easy-to-use,  yet  powerful,  set  of  tools  to  aid  in  the  development  of 
multi-computer  projects. 

1.      Approach 

A  communication  protocol  can  be  optimized  for  large  data  transfers,  or  small 
data  transfers,  or  both.  Efforts  to  optimize  for  both  are  both  complex  and  difficult 
[Ref s.  2,3].  File  transfer  protocols  such  as  FTP  in  the  Defense  Advanced  Research 
Project  Agency  (DARPA)  Internet  domain  and  uucp  in  the  UNIX  domain  can  be  used  for 


large  data  transfers.  Their  overhead1  is  high.  This  overhead  cannot  be  tolerated  in  a 
real-time  problem2.  Our  visual  simulation  efforts  rely  on  small  data  transfers  to 
communicate  among  machines.  These  small  messages  are  typically  commands  and 
changing  status  indicators.  Transferring  the  entire  "world  view"  is  only  a  reasonable  task 
during  initialization  or  reset.  Hence,  we  designed  our  protocols  for  small  messages. 
2.     Design  Criteria 

The  design  criteria  for  developed  protocols  were  simplicity,  ease  of  use, 
portability,  and  efficiency.  Rapid  turnover  of  inexperienced  students  at  the  Naval 
Postgraduate  School  makes  simplicity  of  paramount  importance.  Inevitably,  changes 
will  be  required  and  only  a  simple  protocol  is  easily  modified  to  take  advantage  of  new 
capabilities.  Much  the  same  argument,  and  generally  good  software  design  practice, 
make  ease  of  use  only  slightly  less  important.  Almost  all  operating  system-level  aspects 
are  hidden  from  the  application.  The  number  of  other  machines  to  be  connected  to,  a  use 
of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  the  only 
concerns  for  the  application  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision. 

Portability  dictated  our  use  of  TCP/IP,  an  integral  part  of  the  Defense  Data 
Network  (DDN).  Efficient  use  of  processor  power  was  considered  more  important  than 
efficient  use  of  the  network  resources.  The  network  is  shared  by  the  entire  Computer 
Science  Department,  but  is  not  heavily  loaded. 


1  The  cost  of  creating  a  file  and  then  spawning  a  process  to  send  it  is  high.  On  the  receiving  end,  there  is  the  cost 
of  creating  the  file  and  then  reading  it.  Even  a  zero-cost  file  transfer  protocol  will  require  all  this  overhead. 

2  Large  data  transfers,  in  real-time  systems,  will  not  be  possible  until  100  MByte/Sec  networks  are  commonly 
available. 


B.   BACKGROUND 

1.      Visual  Simulation 

a.      Vision  and  Information  Presentation 

The  eye  has  the  largest  bandwidth  of  any  human  sensory  organ.  Proper 
use  of  this  capability  is  a  challenge  to  all  scientists.  Static  graphs  are  used  in  most 
disciplines  to  show  the  relationships  between  a  limited  number  of  variables.  These  two- 
dimensional  representations  convey  information  more  readily  to  human  beings  than 
would  a  table  of  the  underlying  numbers.  [Ref.  4:  pp.  8-12] 

Time,  a  common  independent  variable,  is  often  one  dimension  on  a  graph. 
The  other  dimension  is  a  single  dependent  variable.  To  portray  additional  variables  in 
one  presentation  is  a  frequently  occurring  requirement.  Various  techniques  such  as 
multiple  colored  lines,  multiple  icons,  and  perspective  drawing  are  used.  With  each 
technique,  only  a  few  additional  variables  are  added  before  the  graph  becomes 
incomprehensible. 

Pictures,  particularly  those  in  color,  have  a  dense  information  content. 
Unless  blind,  we  live  in  a  world  of  pictures.  Human  beings  can  recognize  many 
differences  between  two  similar  pictures.  One  presentation  portrays  many  different 
variables.  When  a  series  of  pictures  are  presented,  the  time  variable  is  easily  correlated 
to  the  actual  time  of  presentation.  When  a  series  of  pictures  is  presented  rapidly,  the 
experience  approaches  reality,  partly  explaining  the  success  of  moving  pictures  and 
television. 

Animation  creates  visual  images  with  an  explicit  time  dimension,  in 
addition  to  two  or  three  spatial  dimensions.  Using  actual  time  to  portray  the 
experimental  time  variable  allows  at  least  one  more  dependent  variable  on  the  display. 
Images  can  be  as  simple  as  a  changing  graph,  or  as  complex  as  a  feature-length  cartoon. 


However,  animation  creates  its  effect  with  the  playback  of  prerecorded  scenes  [Ref.  5]. 
It  is  not  suitable  for  providing  immediate  feedback  to  a  researcher. 

b.  Definition 

Visual  simulation  is  the  creation,  by  computer,  of  a  realistic,  easily- 
modified,  moving  image  from  the  mathematical  model  of  a  phenomenon.  Realism 
implies  high-resolution,  color  graphics.  Movement  implies  adequate  floating  point 
calculation  capacity  to  recalculate  the  model  and  its  graphical  representation  between 
display  refresh  cycles.  Easy  modification  implies  a  well-designed  computer  application. 

Visual  simulation  allows  a  researcher  to  experiment  easily  with  his 
subject.  Ideally,  we  display  a  realistic  approximation  of  part  of  the  world.  The 
experimenter  then  manipulates  some  part  of  this  visual  simulation  and  receives 
immediate  visual  feedback.  The  rapidly  refreshed  display  is  one  key  to  visual  realism. 
Such  a  display  allows  the  direct  manipulation  of  the  visual  simulation,  making  it  easy 
and  intuitive  to  use  [Ref.  6].  Ease  of  use  allows  the  researcher  to  concentrate  on  the 
research  question,  not  the  display  methodology  or  the  computer  interface. 

c.  Examples 

Recent  visual  simulation  projects  of  the  Graphics  and  Video  Laboratory 
include  speed  control  of  autonomous  vehicles  [Ref.  7],  control  of  autonomous  walking 
machines  [Ref.  8],  rule-based  control  of  autonomous  underwater  vehicles  [Ref.  9], 
interactive  moving  platforms  [Ref.  10]  and  combat  vehicle  control  [Ref.  11].  Each  of 
these  projects  exceeded  the  capacity  of  a  single  workstation.  The  speed  control  and 
interactive  moving  platform  projects,  written  entirely  in  C,  used  two  Silicon  Graphics, 
Inc.  IRIS  workstations,  allowing  multiple  simultaneous  views.  The  other  projects  all 
required  a  mle-based  artificial  intelligence  component,  best  programmed  in  Lisp  for  ease 
of  modification.  Running  the  Lisp  subsystem  on  the  IRIS  workstation  gave  an 
unacceptably  low  refresh  rate  and  correspondingly  poor  realism  [Ref.  12].   Placing  the 


Lisp  subsystem  on  another  machine  improved  the  refresh  rate  of  the  IRIS  workstation 
used  for  the  graphics  display. 

2.      Computer  System  Architecture 

Computer  systems  can  have  a  distributed  or  a  non-distributed  architecture. 
Distributed  architectures  have  only  one  characteristic  in  common,  more  than  one 
processor  used  to  accomplish  the  task.  Beyond  this,  many  different  approaches  have 
been  tried  [Ref.  13].  Identical  processors  give  a  homogeneous  architecture.  Different 
processors  give  a  heterogeneous  architecture.  Either  distributed  architecture  may 
incorporate  shared  memory  or  it  may  not.  The  separate  processors  can  be  closely  or 
loosely  coupled.  Communication  between  processors  can  be  via  shared  memory, 
common  bus,  or  some  form  of  communications  network.  Communication  via  some 
combination  of  the  above,  such  as  a  file  server  on  a  local  area  network,  is  also 
common  [Ref.  3].  In  the  Computer  Science  Department  at  the  Naval  Postgraduate 
School,  a  heterogeneous  mix  of  stand-alone  workstations,  file  server  supported 
workstation  clusters,  and  minicomputers  communicates  via  Ethernet. 

Programming  distributed  architectures  has  inspired  creativity.  The 
fundamental  problems  with  distributed  programming  are  the  communications  between 
processes  and  the  temporal  interaction  of  the  processes.  Communicating  sequential 
processes  [Ref.  14],  distributed  processes  [Ref.  15],  and  remote  procedure  calls 
[Refs.  2, 16]  have  all  been  proposed  as  primitives  to  hide  message  passing  from  the 
programmer.  Remote  procedure  calls  [Refs.  2, 3]  and  communicating  sequential 
processes  [Ref.  17]  have  been  implemented.  However,  even  today,  none  of  these  is 
generally  available  as  a  standard  mechanism  across  varied  architectures.  We  have 
created  simpler  (but  less  general)  communication  routines  for  use  among  heterogeneous, 
distributed,  standalone  computers. 


Complex  projects  can  require  the  resources  of  more  than  one  computer. 
Graphics  portions  are  best  handled  by  the  specialized  hardware  of  a  graphics  workstation, 
such  as  a  Silicon  Graphics,  Inc.  IRIS.  Artificial  intelligence  portions  are  best  handled  by 

a  Lisp  machine,  such  as  a  Symbolics  or  a  Texas  Instruments  Explorer**.  Database 
requests  can  be  made  to  a  machine  with  appropriate  database  software.  A  general 
purpose  computer,  such  as  the  Digital  Equipment  Corporation  VAX  ,  can  be  used  for 
additional  processing  power,  file  storage,  or  other  administrative  support.  Providing  easy 
access  across  such  a  mix  of  heterogeneous  computers  is  a  large  task  [Ref.  3].  The  simple 
mechanism  described  in  this  work  gives  communication  access  between  cooperating 
processes  running  on  diverse  hardware.  It  leaves  temporal  design  to  the  application 
developer,  while  providing  the  tools  for  synchronous  and  asynchronous  interaction. 
3.      Communication 

Communications  between  computers  cooperating  on  a  task  can  be  one-to-one, 
many-to-one,  or  one-to-many.  It  can  be  synchronous  or  asynchronous.  Any,  or  all,  of 
these  can  be  required  for  one  visual  simulation. 

One-to-one,  or  direct  connect,  communications  puts  the  lowest  load  on  the 
network  when  there  are  few  messages  to  be  sent.  A  single  virtual  channel  between  the 
two  processes  is  required.  Each  communication  between  any  two  processes  comprises 
one  message.  All  messages  are  known  to  be  intended  for  the  receiving  process.  These 
messages  can  be  sent  synchronously  or  asynchronously.  Direct  connect  communication 
requires  one  action  by  the  sender  and  one  by  the  receiver.    With  more  processors, 


Symbolics  is  a  trademark  of  Symbolics,  Incorporated. 
*  Explorer  is  a  trademark  of  Texas  Instruments  Incorporated. 
**  VAX  is  a  registered  trademark  of  Digital  Equipment  Corporation 


potential  virtual  channels  grow  in  number  geometrically.  For  a  fully  connected  network, 
the  virtual  channels  required  can  exceed  capacity.  The  potential  messages  required  also 
grow  geometrically  in  number. 

One-to-many,  or  broadcast,  communications  puts  the  lowest  load  on  the 
sending  process.  A  message  is  sent  to  all  other  processes  that  are  connected  to  it.  It 
requires  one  action  by  the  sender,  and  two  actions  by  each  receiver  (the  reception  and  a 
decision  on  whether  the  message  is  intended  for  that  receiver).  It  also  places  one  to  n 
messages  on  the  network  (depending  on  how  the  network  and  the  broadcast  protocols  are 
designed).  It  is  primarily  used  in  an  asynchronous  mode,  although  synchronous  protocols 
could  be  designed. 

Many-to-one  communications  puts  the  highest  load  on  the  receiving  process.  It 
requires  two  actions  by  the  receiver  on  every  message  that  is  sent  by  any  connected 
process.  It  is  also  a  primarily  asynchronous  method.  The  receiver  portion  of  a  process 
sees  many-to-one  whenever  broadcast  protocols  are  the  only  ones  used  in  a  visual 
simulation. 

C.    Organization 

The  previous  sections  of  this  chapter  provide  background  on  visual  simulation, 
distributed  architectures,  and  communication  paradigms.  Chapter  II  describes  the 
hardware  and  software  environment  in  the  Computer  Science  Department  at  the  Naval 
Postgraduate  School.  The  protocols  developed  are  discussed  in  Chapter  EH.  Chapter  IV 
describes  the  implementation  of  the  protocols.  Chapter  V  covers  the  use  of  these 
protocols.  The  performance  of  the  protocols  is  detailed  in  Chapter  VI.  Chapter  VII 
concludes  with  a  discussion  of  limitations,  future  extensions  and  research  topics,  and 
summarizes  the  research  conducted.  Listings  of  the  program  source  code  for  each  of  the 
hardware  systems  are  included  as  Appendices. 


n.  existing  System 

A.  INTRODUCTION 

The  distributed  architecture  available  in  the  Naval  Postgraduate  School  Computer 
Science  Department  Graphics  and  Video  Laboratory  is  Ethernet-connected  workstations 
and  minicomputers.    The  workstations  include  IRIS  2400,  3120,  and  4D  graphics, 

Symbolics  36xx  and  TI  Explorer  Lisp,  ISI AI,  and  Sun-3s  .  The  minicomputers  include 
VAX  11/785  and  an  ISIV  minicomputer  complex  providing  database  services.  All 
computers,  except  the  Symbolics  and  TI,  use  some  version  of  UNIX  as  the  primary 
operating  system. 

B.  HARDWARE 
1.      Network 

Ethernet  connects  all  the  computers  in  our  lab.  There  is  a  backbone  network 
and  subnetworks  for  certain  groups  of  computers.  Currently  there  are  two  subnetworks, 
one  for  the  ISIV  minicomputers  and  one  for  the  ISI  AI  workstations.  Subnetworks  are 
planned  for  the  IRIS  workstations,  the  Sun  Workstations  *  ,  and  the  Symbolics  and  TI 
workstations.  Figure  2.1  illustrates  the  network  configuration. 


*  Symbolics  3600,  Symbolics  3640,  Symbolics  3650,  and  Symbolics  3675  are  trademarks  of  Symbolics,  Inc. 

**  Sun-3  is  a  trademark  of  Sun  Microsystems,  Inc. 

***  UNIX  is  a  trademark  of  AT&T  Bell  Laboratories 

****  Sun  Workstation  is  a  registered  trademark  of  Sun  Microsystems,  Inc. 
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Sun  File  Server/Diskless  Workstations 


suns2 


C 


suns20 


suns21 


ail 


ai7 


ai8 


isivl 

isiv7 

isiv8 

CS  Backbone  Ethernet 
CS  Subnetwork 


Figure  2. 1     Network  Configuration 


All  computers  support  TCP/IP  protocols.  The  Symbolics  Lisp  machines  also 
use  the  CHAOS  protocol  to  provide  file  server  services  from  syml  to  the  other  Symbolics 
machines.  This  logical  local  area  network  (LAN)  uses  the  Ethernet  backbone  for  its 
messages.  The  Sun  file  servers  also  support  their  diskless  nodes  over  the  backbone 
Ethernet. 

2.      Workstations 

a.  Silicon  Graphics,  Inc.  IRIS 

Table  2.1  shows  the  IRIS  workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  proprietary  Geometry  Engines  in  each  of  these 
workstations  allows  three  dimensional  color  graphics  displays  to  be  generated  and 
updated  in  real-time.  The  primary  use  of  these  machines  is  for  color  graphics. 

b.  ISI AI 

Table  2.2  shows  the  ISI  AI  workstation  configurations.  Only  ai8  is 
connected  directly  to  the  backbone  Ethernet.  The  other  workstations  are  connected  to  it 
in  a  subnetwork.  These  workstations  are  used  primarily  for  artificial  intelligence 
projects.  The  ai8  machine  provides,  as  well  as  a  gateway  to  the  backbone  Ethernet,  file 
server  support  for  the  other  workstations.  Their  high  resolution  black  on  white  monitors, 
although  bitmapped,  have  rudimentary  graphics  capabilities. 


Table  2.1 

IRIS  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 

No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 
Planes 

Floating 

Point 

Accelerator 

Screen 
Resolution 

irisl 
iris2 
iris3 
iris4 

4D/70G 

2400  Turbo 

3120 

4D/70G 

8 
6 
4 
8 

380MB 
144MB 
144MB 
380MB 

56 
32 
32 
56 

N/A 
Y 

N 
N/A 

1280x1024 
1024x768 
1024x768 
1280x1024 

10 


Table  2.2    ISI AI  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 

Memory 

Disk 

Bit 

Screen 

No. 

(MBytes) 

Capacity 

Planes 

Resolution 

ail 

V8WS 

4 

101MB 

2 

1280x1024 

ai2 

V8WS 

4 

101MB 

2 

1280x1024 

ai3 

V8WS 

4 

101MB 

2 

1280x1024 

ai4 

V8WS 

4 

101MB 

2 

1280x1024 

ai5 

V8WS 

4 

101MB 

2 

1280x1024 

ai6 

V8WS 

4 

101MB 

2 

1280x1024 

ai7 

V8WS 

4 

101MB 

2 

1280x1024 

ai8 

V16WS 

4 

403MB 

2 

1280x1024 

c.  Sun-3/50 

Table  2.3  shows  the  Sun  Workstation  configurations.  All  are  connected 
directly  to  the  backbone  Ethernet.  The  black-on-white  monitors  of  the  Sun  diskless 
workstations  are  primarily  used  for  administrative  tasks  at  this  time. 

d.  Symbolics  36xx 

Table  2.4  shows  the  Symbolics  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  Symbolics  workstations  are  used  for  a 

Table  2.3     SUN  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 

Memory 

Disk 

Bit 

Screen 

No. 

(MBytes) 

Capacity 

Planes 

Resolution 

suns  J 

3/1 80S 

12 

490MB 

2 

1280x1024 

sunlO 

3/50 

4 

N/A 

2 

1280x1024 

sun  11 

3/50 

4 

N/A 

2 

1280x1024 

sun  12 

3/110 

4 

N/A 

2 

1280x1024 

sunl3 

3/110 

4 

N/A 

2 

1280x1024 

sunl4 

3/60 

4 

N/A 

2 

1280x1024 

sun  15 

3/60 

4 

N/A 

2 

1280x1024 

sun  16 

3/60LC 

4 

N/A 

10 

1280x1024 

sun  17 

3/50 

4 

N/A 

2 

1280x1024 

sun  18 

3/50 

4 

N/A 

2 

1280x1024 

sunl9 

3/50 

4 

N/A 

2 

1280x1024 

suns2 

3/180S 

12 

490MB 

2 

1280x1024 

sun20 

3/60LC 

4 

N/A 

10 

1280x1024 

sun21 

3/60LC 

4 

N/A 

10 

1280x1024 

11 


Table  2.4     SYMBOLICS  WORKSTATION  CONFIGURATIONS 


Nickname 

Model 
No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 

Planes 

Color 

Screen 
Resolution 

syml 
sym2 
sym3 
sym4 

3675 
3640 
3640 
3650 

5 
1 
1 
5 

1GB 
180MB 
180MB 
512MB 

24 
1 
8 
1 

Y 

N 
Y 

N 

1280x1024 
1280x1024 
1024x1024 
1280x1024 

variety  of  research  projects  involving  artificial  intelligence.  The  syml  machine  provides 
file  server  support  for  the  other  Symbolics  machines  using  the  Chaos  protocol  and  its  one 
GigaByte  (unformatted)  storage  capacity.  The  color-capable  systems  are  used  to  display 
static  information  with  color  providing  an  easier  human  interface, 
e.      Texas  Instruments  Explorer 

Table  2.5  shows  the  Explorer  workstation  configurations.  All  are 
connected  directly  to  the  backbone  Ethernet.  The  TI  Explorers  are  also  used  for  artificial 
intelligence  projects.  They  have  the  least  graphical  capabilities  of  any  of  the 
workstations. 

3.     Digital  Equipment  Corporation  VAX  1 1/785 

Table  2.6  shows  the  two  DEC  VAX  11/785  computer  configurations.  Both  are 
connected  directly  to  the  backbone  Ethernet.  Only  the  unixl  machine  was  included  in 
this  project.   The  vmsl  machine  may  not  be  available  in  the  future,  so  the  effort  to 


Table  2.5     EXPLORER  WORKSTATION  CONFIGURATIONS 

Nickname 

Model 
No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 
Planes 

Screen 
Resolution 

expl 
exp2 
exp3 
exp4 

I 
I 
I 
I 

4 
8 
8 
2 

280MB 
420MB 
420MB 
140MB 

1 
1 

1 
1 

1024x808 
1024x808 
1024x808 
1024x808 

*  DEC  is  a  registered  trademark  of  Digital  Equipment  Corporation 
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Table  2.6     VAX  CONFIGURATIONS 


Nickname 

Model 
No. 

Memory 
(MBytes) 

Disk 
Capacity 

Operating 
System 

unixl 
vmsl 

11/785 

11/785 

24 
8 

1395MB 

1442MB 

UNIX 
VMS 

develop  appropriate  code  was  deemed  unnecessary.  The  unixl  machine  is  nps-cs.arpa 
on  MILNET  and  is  the  sole  external  access  point  to  other  machines  connected  locally  via 
Ethernet.  It  supports  the  various  dial-up  lines,  as  well  as  other  administrative  functions. 
4.      ISIV  minicomputers 

The  computers  in  Table  2.7  make  up  the  ISIV  minicomputer  complex.  Only 
isiv8  is  connected  to  the  backbone  Ethernet.  The  other  machines  are  connected  to  isiv8 
in  an  Ethernet  subnetwork.  The  ISIV  minicomputers  provide  a  high  performance,  multi- 
backend  distributed  database.  Any  of  the  high-resolution  black  on  white  monitors  can  be 
used  with  any  of  the  hosts  on  the  subnetwork.  The  character  displays  can  also  be  used  on 
any  of  the  subnetwork  hosts.  The  graphics  capabilities  of  these  machines  are  limited. 


Table  2.7     ISIV  DATABASE  MACHINE  CONFIGURATION 

Nickname 

Model 

No. 

Memory 
(MBytes) 

Disk 
Capacity 

Bit 
Planes 

Screen 
Resolution 

: 
: 
i 
: 
i 
i 
i 
; 

isivl 
isiv2 
isiv3 
isiv4 
isiv5 
isiv6 
isiv7 
isiv8 
isiv9 

V24S 
V24WS 
V24WS 
V24WS 

V24S 

V24S 
V24WS 
V24WS 

V24S 

4 
4 
4 
4 
4 
4 
4 
4 
4 

602MB 
500MB 
602MB 
500MB 
602MB 
602MB 
602MB 
459MB 
602MB 

N/A 

2 

2 

2 
N/A 
N/A 

2 

2 
N/A 

80x24char 

1280x1024 

1280x1024 

1280x1024 

80x24char 

80x24char 

1280x1024 

1280x1024 

80x24char 
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C.    Software 

1.  UNIX  Machines 

Two  versions  of  UNIX  are  commonly  used.  The  machines  purporting  to  use 

System  V*,  also  incorporate  characteristics  of  4.2BSD  and  4.3BSD.    The  relevant 
incorporation  is  the  Berkeley  socket  mechanism. 

a.  4.3BSD 

A  "pure"  4.3BSD  system  (4.3  BSD  UNIX  #11)  exists  only  on  unixl.  The 
ISIV  minicomputers  use  4.2  BSD  UNK  Release  3.07,  with  a  multi-backend  database 
system  installed  [Refs.  18-20].  The  ISI  AI  workstations  use  IS68K  4.3  BSD  UNK:  4.0D 
#2. 

b.  System  V 

The  IRIS  4D  systems  use  UNK  System  V-based  version  4D1-2.2.  The 
IRIS  2400  and  3120  systems  use  UNK  System  V-based  version  GL2-W3.6.  Both  have 
extensive  4.3BSD  extensions.  The  Sun-3  uses  an  almost  System  V  version  of  4.2BSD 
UNK.  The  currently  installed  release  is  3.4. 

2.  Lisp  Machines 

a.  Genera 

The  Symbolics  Lisp  Machines  first  used  Genera  6.0  software.  All 
machines  are  now  on  Genera  7.1. 

b.  Explorer 

The  TI  Explorer  lisp  machine  first  used  Explorer  version  1.0.2  software. 
All  machines  are  now  on  version  3.4  except  expl,  which  is  still  on  version  3.2. 


UNIX  System  V  is  a  trademark  of  AT&T  Bell  Laboratories 
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D.      SUMMARY 

The  configuration  described  above  is  constantly  changing.  Additional  machines  are 
acquired.  Older  machines  receive  hardware  upgrades.  The  network  is  reconfigured. 
Software  releases  are  updated  (especially  4.2BSD  UNIX  to  4.3BSD  UNIX).  The 
fundamental  needs  for  distributed  computation  in  this  heterogeneous  environment 
remain. 
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in.  PROTOCOLS 

A.  INTRODUCTION 

Our  visual  simulation  efforts  rely  on  small  data  transfers  to  communicate  among 
machines.  These  small  messages  are  typically  commands  and  changing  status  indicators. 
Hence,  we  optimized  our  protocols  for  small  messages.  Overhead  to  optimally  encode 
and  decode  packets  was  deemed  inappropriate.  The  design  criteria  for  developed 
protocols  were  simplicity,  ease  of  use,  portability,  and  efficiency. 

B.  DIRECT  CONNECTION 

The  client/server  paradigm  is  used  for  direct  connection.  The  client  requests 
services  from  the  server,  so  establishing  communications  is  asymmetrical.  Once 
communications  are  established,  however,  the  protocol  used  is  completely  symmetrical. 
[Ref.  21:  p.  17] 

1.      High-Level  Protocol 

The  variety  of  data  types  supported  is  limited  (see  Table  3.1).  Each  message 
contains  exactly  one  instance  of  one  type  of  data.  All  integer  or  float  data  is  converted  to 
an  ASCII  character  string  before  it  is  sent.  It  is  converted  back  to  the  proper  type  after 

Table  3 . 1     DATA  TYPES  SUPPORTED 


Type 

Length 
(Bytes) 

Elements 

Code 

Available 

character 

1 

single 

B 

Y 

array 

C 

Y 

integer 

4 

single 

I 

Y 

array 

J 

N 

float 

4 

single 

R 

Y 

array 

S 

N 
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reception.  While  the  conversion  is  unnecessary  when  communicating  between  similar 
architectures,  it  greatly  simplifies  the  task  of  communicating  between  fundamentally 
different  architectures.  Knowledge  of  the  other  machine's  architecture  is  not  required. 
The  inherent  portability  of  this  solution  outweighs  the  processing  cost. 

A  message  is  created  with  three  fields.  The  type  field  is  a  one-character  field. 
It  contains  the  appropriate  code  from  Table  3.1.  The  length  field  is  a  four-character  field. 
It  contains  an  ASCII  string  from  0001  to  9999.  This  string  gives  the  length  of  the  data 
field.  The  data  field  is  a  variable  length  field  containing  the  ASCII  representation  of  the 
data  element.  Figure  3.1  illustrates  these  fields. 

While  C  programmers  are  continuously  concerned  with  data  types,  Lisp 
programmers  are  not.  The  Lisp  routines  support  arrays  of  characters,  single  integers,  and 
single  floating  point  numbers.  Each  of  these  is  an  object.  Objects,  not  types  (as  implied 
in  Table  3.1),  are  received  and  sent  by  lisp  applications.  The  underlying  protocol  is  the 
same,  the  application  interface  is  different3. 


Position 


1 

2 

|    3    |    4 

5 

6 

7    |   ... 

1    n 

T 

y 
p 

Length 

Data 

e 

Figure  3.1     Message  Format 


3  Chapter  5  discusses  applications'  use. 
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2.      Supporting  Protocols 

Full-duplex  stream  sockets  are  used  to  provide  sequenced,  reliable  connection 

between  machines.  The  sockets  are  created  in  the  DARPA  Internet4  domain.  The 
Internet  pseudo-protocol  is  used  [Ref.  22].  No  out-of-band  capability  was  included.  We 
could  not  envision  a  use  for  it,  since  our  protocol  is  inherently  asynchronous.  If  a  strictly 
synchronous  protocol  was  used,  out-of-band  transmission  might  be  necessary  to  interrupt 
for  an  urgent  message.  In  an  asynchronous  protocol,  however,  encoding  the  next 
message  gives  the  same  effect.  Processing  overhead  for  encoding  is  no  greater  than  for 
continuous  monitoring  for  an  out-of-band  message.  With  only  a  small  volume  of  data 
transfers  expected,  no  urgent  message  waits  very  long. 

Two  ports,  each  with  its  own  stream  socket,  are  used  for  each  channel  between 
machines.  Although  full-duplex,  the  stream  sockets  are  used  in  a  simplex  mode.  The 
separate  sockets  are  used  because  two  processes  cannot  be  bound  to  the  same  socket  at 
the  same  time.  Two  separate  UNIX  processes  then  monitor  the  independent  send  and 
receive  sockets.  Blocking  sockets  are  used,  avoiding  processing  overhead  for  busy- 
waiting.  While  non-blocking  sockets  are  available  in  4.3BSD  [Ref.  21:  p.  25],  they  were 
not  explicitly  available  in  4.2BSD  [Ref.  22].  Operating  systems  might  include  4.2BSD 
sockets  rather  than  4.3BSD  versions  and  so  the  blocking  socket  mechanism  was  deemed 
more  portable.  Both  TCP/IP  and  the  C  routines  provide  buffering. 

On  the  TI  Explorer,  sockets  were  also  blocking5.  Direct  access  was  made  to 
the  TCP  methods  provided.  Lisp  streams  are  used  for  the  Symbolics  lisp  routines.  The 


4  This  is  the  underlying  mechanism  of  the  Defense  Data  Network  (DDN)  and  was  chosen  for  its  wide  availability 
and  applicability  to  Department  of  Defense  problems. 

5  Version  1 .0  of  the  Explorer  TCP/DP  software  uses  blocking  sockets.   Version  2.0  uses  non-blocking  sockets. 
There  has  been  no  update  of  this  system's  TI  Explorer  lisp  routines  to  version  2.0. 
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lisp  stream  mechanism  isolates  the  code  from  the  issues  revolving  around  blocking 
versus  non-blocking  sockets. 

C.      BROADCAST 

A  broadcast  message  is  sent  to  all  machines  on  a  local  Ethernet.  Those  machines 
that  are  waiting  for  some  broadcast  message  will  probably6  receive  it.  If  a  machine  on  a 
subnetwork  is  to  get  a  broadcast  message,  an  application  must  run  on  the  gateway 
machine  that  will  rebroadcast  on  the  subnetwork  any  messages  received  on  the  backbone 
Ethernet.  Machines  not  expecting  a  broadcast  message  must  nevertheless  process  it  and 
reject  it  as  inappropriate.  The  extra  load  on  all  machines  connected  to  the  Ethernet 
restricts  broadcasting  to  infrequent  occurences  until  most  of  the  machines  used  in 

simulations7  are  on  a  private  subnetwork. 

1.  High-Level  Protocol 

We  expect  users  of  the  broadcast  protocol  to  mix  its  use  with  the  use  of  direct 
connections.  The  same  data  types  and  messages  are  supported  (see  Table  3.1). 

2.  Supporting  Protocols 

Full-duplex  datagram  sockets  are  used  to  provide  connectionless  broadcast 
capability.  The  sockets  are  created  in  the  DARPA  Internet  domain.  As  with  our  use  of 
stream  sockets  for  the  direct  connection  protocol,  we  use  these  full-duplex  datagram 
sockets  in  a  simplex  mode.  We  use  a  sending  socket  for  one-way  sending  of  a  broadcast 
message  to  all  other  machines  on  a  single  network  or  subnetwork.  We  use  a  receiving 
socket  for  one-way  receiving  from  a  specific  broadcasting  machine  on  the  network  or 


6  Unlike  the  direct  connect  protocol,  the  broadcast  protocol  does  NOT  guarantee  reception.  Trying  to  provide 
such  a  guarantee  requires  a  feedback  machanism  so  that  the  sender  knows  that  the  machines  expected  to  receive  the 
broadcast  did  so.  This  is  difficult  without  resorting  to  a  direct  connection  or  flooding  the  network  with  messages. 

7  The  IRIS  machines  and  the  Lisp  machines  are  the  ones  principally  used  for  visual  simulation. 
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subnetwork.   Direct  connection,  with  its  use  of  guaranteed  reliable  stream  sockets,  is 
used  for  any  other  communication,  including  return  messages.  [Ref.  21:  pp.  32-34] 

As  in  the  direct  connection  protocol,  independent  UNIX  processes  are  bound  to 
the  sockets.  Since  broadcasting  is  a  one-way  activity,  a  sender  or  receiver  only  spawns 
one8  UNIX  process. 

D.    Summary 

By  building  our  high-level  protocols  on  top  of  DARPA  TCP/IP  standards,  we  provide 
the  highest  degree  of  portability  possible  today.  By  using  full-duplex  stream  sockets  and 
datagram  sockets  in  a  simplex  mode,  we  do  not  make  full  utilization  of  a  socket's 
capabilities.  However,  this  concern  is  outweighed  by  the  increased  simplicity  and 
resultant  maintainability  of  the  code.  The  use  of  ASCII  character  strings  for  the  messages 
is  simple  and  makes  interconnection  with  diverse  architectures  straightforward. 


8  If  broadcasting  were  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  n  processes. 
If  direct  connection  was  used  exclusively  for  complete  connectivity,  each  of  n  machines  would  spawn  2n-2  processes. 
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IV.  Implementations 

A.  Introduction 

The  first  connection  was  between  the  IRIS  2400-Turbo  and  TI  Explorer.  Then  the 
Symbolics  Lisp  machines  were  included.  These  routines  have  had  extensive  use 
[Refs.  8,9, 11].  The  IRIS  functions  were  updated  for  the  IRIS  4D,  coincidentally 
providing  Mex  support  on  the  older  IRIS  machines.  Broadcast  capability  was  added  for 
UNIX-based  machines.  A  port  to  4.3BSD  UNIX  (application  calls  unchanged)  was  begun. 

B.  System  V  unix 

All  our  System  V  UNIX-based  systems  include  the  socket  mechanism  first 
introduced  by  4.2BSD.  Sockets  are  a  key  aspect  of  all  implementations.  We  expect  they 
will  become  part  of  System  V  or  its  successors  [Ref.  23].  The  System  V-unique 
semaphore  and  shared  memory  interprocess  communication  (IPC)  capabilities  are  also 
used. 

1.      Silicon  Graphics.  Inc.  IRIS  2400 
a.      Sockets 

The  socket  was  introduced  in  4.2BSD  as  the  preferred  metaphor  for  IPC.  It 
was  easy  and  efficient  to  implement  and  the  select  mechanism  could  be  used  to 
implement  remote  procedure  calls,  if  desired  [Ref.  23].  System  V  had  no  comparable 
mechanism  until  version  3  was  released  with  streams.  The  BSD  sockets  were  included 

by  many  vendors,  Silicon  Graphics,  Inc.  included9.  While  the  use  of  sockets  could  be 


9  The  System  V  version  available  on  the  IRIS  machines,  at  the  start  of  the  project,  was  version  2  and  so  streams 
were  not  considered. 
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replaced  with  streams,  device  drivers  would  have  to  be  written.  The  advantage  of 
streams  is  the  ability  to  filter  them  between  streamhead  and  the  actual  device  driver. 
These  filters,  however,  reside  in  the  kernel's  address  space  and  have  the  kernel's 
permissions  [Ref.  24].  In  our  environment,  the  potential  performance  increase  is  not  as 
important  as  the  requirement  for  simplicity. 

The  system  call  for  socket  creation  is  socket.  The  system  calls  supporting 
socket  configuration  are  setsockopt,  bind,  connect,  and  accept10  [Ref.  22].  To  simplify 
their  use,  these  are  all  repackaged  into  four  high  level  routines:  connect  server  and 
connect  client  for  direct  connection,  start  broadcast  and  broadcast  receive  for 
broadcast.  These  routines  are  encapsulated  in  netV.c.  netV.c  can  be  separately  linked 
with  any  application  that  needs  to  make  a  server/client  connection  using  stream  sockets 
or  a  broadcasting  connection  using  datagram  sockets.  Table  4.1  describes  the  four 
routines. 

Using  the  socket  number11,  a  process  can  transmit  data  through  the  socket. 
In  our  system,  sockets  for  inter-computer  communication  are  created  and  used  by  the 
send  and  receive  processes  exclusively.  The  file  netV.c  is  not  linked  with  the  application 
at  all. 


10  The  accept  system  call  is  only  relevant  to  stream  sockets.  The  setsockopt,  bind,  and  connect  system  calls  are 
used  with  both  stream  sockets  and  datagram  sockets. 

11  In  the  direct  connect  protocol,  the  server  process  reads  from  and  writes  to  a  remote  socket  number.  The  client 
process  reads  from  and  writes  to  its  local  socket  number.  The  reason  for  this  is  that  a  server  could  be  connected  to  dif- 
ferent clients  (although  not  in  our  implementation)  at  different  times.  The  client,  meanwhile,  is  only  going  to  connect 
to  the  one  server.  In  the  Internet  domain,  all  necessary  routing  information,  for  either  server  or  client,  is  contained  in  a 
sockaddrin  structure  and  is  accessed  (transparently)  via  the  socket  number. 

In  the  broadcast  protocol,  both  the  broadcaster  and  receiver!  s)  use  their  local  socket  number  because  they  are 
using  connectionless  datagram  sockets.  The  routing  information  is  also  contained  in  a  sockaddrjn  structure. 
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Table  4. 1     SOCKET  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

connect_server 

Creates    socket.     Binds   that 
socket  to  remote  client  ad- 
dress and  port.    Waits  to  ac- 
cept the  remote  client  con- 
nection.   Returns  the  socket 
number  for  the  remote  client. 

int  connect_server(  remote_client_name,  port_number  ) 
char  remote_client_name[]; 
int  port_number, 

remote_socket  =  connect_server(  remote_client_name, 

port_number ) 

connect_client 

Creates    socket.     Binds  that 
socket  to  remote  server  ad- 
dress   and    port.     Connects 
with  remote  server.    Returns 
the  local  socket  number. 

int  connect_client(  remote_server_name,  port_number ) 
char  remote_server_name(J; 
int  port_number, 

local_socket  =  connect_client(  remote_server_name, 

port_number ) 

start_broadcast 

Creates    socket.     Sets   it   to 
broadcast  mode.    Binds  it  to 
local   address   and   specified 
local  port.    Returns  the  local 
socket  number. 

int  start_broadcast(  port_number ) 

int  port_number, 

local_socket  =  start_broadcast(  port_number ) 

broadcast_receive 

Creates  socket.    Binds  it  to 
local    address    and    specified 
port.     Adds  broadcaster  ad- 
dress and  port.    Returns  the 
local  socket  number. 

int  broadcast_receive(  broadcaster_name,  broadcaster_port ) 
char  broadcaster_name[]; 
int  broadcaster_port; 

local_socket  =  broadcast_receive(  broadcaster_name, 

broadcaster_port ) 

b.      Semaphores 

The  semaphore  mechanism  was  chosen  as  the  least  expensive,  in  both 
space  and  time,  for  communication  between  processes.  Signals  could  have  been  used, 
but  implementation  would  have  been  more  complex  and  less  reliable.  Signal-based 
communication  functions  would  also  have  been  more  difficult  for  the  application 
programmer  to  use  [Ref.  25:  p.  10].  There  are  two  semaphore  ids  maintained  for  each 

connection12.  One  is  used  to  communicate  with  the  send  process;  one  is  used  to 
communicate  with  the  receive  process.  The  two  semaphores  are  both  used  to  signal  their 
process  when  it  is  safe  to  proceed.  A  send  process  is  permitted  to  proceed  only  after  the 


12  Two  semaphore  ids  are  required  for  direct  connect  protocol  connections  since  both  a  send  and  a  receive  pro- 
cess are  spawned.  Two  semaphore  ids  are  still  created  for  broadcast  protocol  connections,  even  though  only  one  pro- 
cess is  spawned. 
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application  has  requested  a  write  action13  on  the  channel.  A  receive  process  is  permitted 
to  proceed  only  after  the  application  has  read  all  data  from  the  shared  memory  buffer. 
Neither  the  send  nor  the  receive  process  is  executing  more  than  absolutely  necessary, 
assuring  maximum  availability  of  the  local  processor  to  the  application. 

The  system  calls  supporting  semaphores  are  semget,  semop,  and  semctl. 
To  simplify  their  use,  they  are  repackaged  into  three  high  level  routines:  semtran,  P,  and 
V  [Ref.  25:  pp.  188-190].  These  routines  (and  a  support  routine  semcall)  are 
encapsulated  in  semaphores.  It  can  be  separately  linked  with  any  application  that  needs 
semaphores.  Table  4.2  describes  the  three  routines, 
c.      Shared  Memory 

A  cost  barrier  to  IPC  in  UNIX  is  the  cost  of  copying  data  from  one  process 
to  the  kernel  and  then  from  the  kernel  to  another  process.  Using  a  shared  memory 
segment,  as  a  buffer,  minimizes  this  overhead.  To  further  reduce  overhead  from  system 
calls,  only  a  single  segment  is  created.  An  application  accesses  the  entire  segment,  while 
a  send  or  receive  process  accesses  only  its  preassigned  section.  Figure  4.1  displays  the 
layout.  The  message  area  of  each  section  is  used  for  several  purposes.  It  is  formatted  as 

Table  4.2     SEMAPHORE  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

semtran 

Creates  a  semaphore  associ- 
ated with  a  key.    Returns  a 
semaphore  id. 

int  semtran(  key  ) 

int  key; 

sid  =  semtran(  key  ); 

P 

Acquire  semaphore 

void  P(  sid ) 
int  sid; 

V 

Release  semaphore 

void  V(  sid ) 
int  sid; 

13  The  data  must  also  be  valid  in  the  shared  memory  buffer.  All  this  is  transparent  to  the  application,  which  only 
issues  a  write  command. 
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Figure  4.1     Shared  Memory  Segment  Data  Assignment 

a  long  (4-byte)  integer.  Table  4.3  describes  the  meaning  of  three-state  values  placed  in 
this  area. 

Table  4.3     SHARED  MEMORY  MESSAGES 


Value 

Meaning 

to 

send 

Meaning 
to 

receive 

Meaning 

to 

Application 

positive 

Data  of  length  given  is 
in      shared      memory, 
ready  to  be  sent. 

Application     has     not 
finished    reading    data 
from  shared  memory. 

send:  Data  in  shared  memory 
has  not  yet  been  sent  to  other 
machine. 

receive:  Valid  data  of  length 
given  is  in  shared  memory, 
ready  to  be  read. 

zero 

Nothing    ready    to    be 
sent. 

Application    has    read 
data       from        shared 
memory.           Message 
from  other  machine  can 
be  read,  up  to  LAR- 
GESTREAD bytes. 

send:  Previous  message  has 
been    sent.     Ready    to    send 
next  message. 

receive:    No    valid    data    in 
shared  memory. 

negative 

Signal  to  terminate. 

Signal  to  terminate. 

N/A 
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The  system  calls  supporting  shared  memory  are  shmget,  shmat,  shmdt,  and 
shmctl  [Ref.  25:  pp.  192-198].  To  simplify  their  use,  they  are  repackaged  into  four  high 
level  routines:  sharedsegment,  dynamicsharedsegment,  detachsharedsegment,  and 
deletesliaredsegment.  These  routines  (and  a  support  routine  attach _yvithin_datasegment) 
are  encapsulated  in  shareseg.c.  It  can  be  separately  linked  with  any  application  that 
needs  shared  memory.  Table  4.4  describes  the  four  routines. 

The  implementation  of  shared  memory  on  the  IRIS  2400  and  IRIS  3120 
was  a  surprise.  A  basic  UNIX  memory  allocation  scheme  is  shown  in  Figure  4.2.  Each 
process  has  its  own  text,  data,  and  stack  sections.  Neither  the  relative  locations  of  these 
sections  nor  the  direction  of  growth  for  stack  and  data  sections  is  specified  for  UNIX. 
The  shared  memory  segments  are  logically  part  of  the  data  section  [Ref.  26:  p.  151]. 
Table  4.4     SHARED  MEMORY  SUPPORT  FUNCTIONS 


Function 

Description 

Use 

sharedsegment 

Creates  (if  not  already  in  ex- 
istence)   a    shared    memory 
segment    associated    with    a 
key.    Attaches  application  to 
that  shared  memory  segment. 
Returns    a    shared    memory 
segment     address     and     id. 
Does  not  permit  subsequent 
dynamic  memory  allocation. 

char  *sharedsegment(  key,  nbytes,  shmid  ) 

long  key; 

long  nbytes; 

int  *shmid; 

segment  =  sharedsegment(  key,  nbytes,  shmid ) 

dynamicsharedsegment 

Creates  (if  not  already  in  ex- 
istence)   a    shared    memory 
segment    associated    with    a 
key.   Attaches  application  to 
that  shared  memory  segment. 
Returns    a    shared    memory 
segment  address  and  id.  Per- 
mits     subsequent      dynamic 
memory  allocation. 

char  *dynamicsharedsegment(  nummachines, 
key,  nbytes,  shmid,  freespace  ) 

int  nummachines; 
long  key; 
long  nbytes; 
int  *shmid; 
int  freespace; 

segment  =  dynamicsharedsegment(         num- 
machines, key,  nbytes,  shmid,  freespace  ) 

detachsharedsegment 

Detach  shared  memory  seg- 
ment from  application 

void  detachsharedsegment  segment ) 
char  *segment; 

deletesharedsegment 

Delete  shared  memory  seg- 
ment 

void  deletesharedsegment(  segment,  shmid  ) 
char  *segment; 
int  shmid; 
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Figure  4.2     UNIX  Memory  Allocation 


Actual  implementation  is  left  to  the  team  porting  UNIX  to  the  machine.  The  Silicon 
Graphics,  Inc.  implementation  attaches  a  shared  memory  segment  to  the  first  available 
valid14  address  within  the  data  section.  However,  the  beginning  of  shared  memory 
delimits  the  size  of  all  other  sections  [Ref.  26:  pp.  367-370].   Figure  4.3  illustrates  this 


14  Shared  memory  segments  must  begin  on  a  page  boundary.  This  allows  easy  table-driven  access  by  multiple 
processes.  On  the  IRIS  2400  and  3120  machines,  the  Motorola  68000  architecture  is  used.  The  pages  are  8 KBytes. 
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Figure  4.3     IRIS  2400  Default  Shared  Memory  Attachment 

relationship.  While  no  dynamic  memory  calls15  are  made,  the  default  arrangement  works 
fine.  But  when  dynamic  memory  allocation — linked  lists  and  makeobj()  calls  are 
examples — is  needed,  the  technique  fails. 

To  allow  dynamic  memory  allocation,  the  shared  memory  segment  must 
be  attached  at  an  address  beyond  the  greatest  ever  required  for  regular  data.  Dynamic 
allocation  can  then  occur  without  reaching  the  shared  memory  segment.  Attaching  at  an 
unknown  address  both  within  the  data  section  and  sufficiently  beyond  existing  data  to 
permit  dynamic  data  section  growth,  can  be  done  at  least  two  ways.  First,  the  data 
section  can  be  expanded  until  it  is  as  large  as  possible,  then  the  shared  memory  segment 


13  Dynamic  memory  allocation  is  made  with  system  call  brk  or  alternate  sbrk.  Library  functions  malloc,  realloc, 
and  calloc  use  brk  and  so  also  do  dynamic  memory  allocation. 
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can  be  attached  at  a  valid  location  just  inside  this  maximum  value.  While  minimizing 
application  programmer  effort,  this  technique  requires  many  system  calls  to  grow  the 
data  section.  It  also  has  the  fatal  flaw  of  limiting  the  stack  section,  if  the  stack  section 
and  data  section  grow  into  the  same  unallocated  memory.  Second,  the  application  can  be 
required  to  prespecify  the  maximum  amount  of  dynamic  memory  allocation  it  might  use. 

The  solution  adopted  is  adding  a  freespace  parameter  to  the 
sharedsegment  function;  and  renaming  it  the  dynamicsharedsegment  function.  The 
sharedsegment  function  was  retained  for  backward  compatibility.  The  freespace 
parameter  gives  the  caller  the  ability  to  specify  the  maximum  additional  memory 
required  for  the  application.  A  request  for  this  additional  space  is  made  before  the  shared 
memory  segment  is  attached.  After  acquiring  (and  freeing)  the  additional  space,  the  next 
available  address  is  determined  and  the  shared  memory  segment  is  attached  to  the  next 
valid  address.  We  have  now  established  the  shared  memory  segment  beyond  the 
specified  growth  of  the  application's  data. 

When  multiple  machines  are  connected  together,  there  must  be  a  separate 
shared  memory  buffer  for  each  channel.  There  is  no  way  to  connect  a  second  shared 
memory  segment.  The  solution  adopted  is  adding  a  nummachines  parameter  to  the 
dynamicsharedsegment  function.  The  nummachines  parameter  requires  the  application 
developer  to  specify,  in  advance,  the  maximum  number  of  channels  that  can  be  created  in 
the  application.  The  first  dynamicsharedsegment  call  establishes  a  shared  memory 
segment  big  enough  for  nummachines  maximum  requested  channels.  Subsequent 
dynamicsharedsegment  calls  return  the  same  shared  memory  id  as  the  first;  but  return  a 
different  address  within  the  segment.  Since  the  application  does  not  directly  access  these 
functions,  there  were  no  problems  caused  by  this  parameter  list  change. 
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The  shared  memory  functions  are  isolated  from  the  application  by  the 
machinepath,  dynamicmachinepath,  dynamicmachinepaths,  and  deletemachinepath 
functions16.  For  the  direct  connect  protocol,  each  machinepath,  dynamicmachinepath,  or 
dynamicmachinepaths  call  spawns  both  a  send  and  a  receive  process.  For  the  broadcast 
protocol,  these  calls  spawn  only  a  send  process  (for  the  broadcaster)  or  a  receive  process 
(for  the  receiver).  In  all  cases,  the  spawned  processes  issue  a  sharedsegment  call  to 
attach  to  the  shared  segment  earlier  created  by  the  spawning  function.  A  command  line 
parameter  is  passed  providing  the  offset  into  the  shared  memory  segment  that  the 
spawned  process  is  to  use.  Figure  4.4  illustrates  a  system  with  three  machines  and  two 
channels. 

d.      Buffering 

(1)  Direct  Connect.  When  a  receive  process  is  quiescent,  waiting  for 
the  application  to  read  from  the  shared  memory  buffer,  anything  sent  to  it  is  buffered  by 
TCP/IP.  The  buffering  provides  the  reliable  delivery  promised  by  a  stream  socket.  The 
next  read  command  will  deliver  up  to  LARGESTREAD  bytes  into  the  receive  data  area  of 
the  shared  memory  buffer.  Since  the  messages  are  variable  length,  there  cannot  be  a 
guarantee  that  only  one  message  was  read17.  Multiple  messages  might  be  in  the  shared 
memory  buffer.  A  partial  message  might  be  in  the  last  bytes. 

The  shared  memory  buffer  management  is  handled  by  the  various 
read  functions18  provided.  Each  read,  requested  by  the  application,  is  satisfied  from  the 


16  See  Chapter  5,  Sections  A.l.b(l)  and  A.l.b(3)  for  more  information  on  these  functions. 

17  The  idea  to  pad  all  messages  to  some  arbitrary  size  was  considered  and  rejected.  Whatever  size  was  chosen 
would  always  be  too  small  for  some  character  array.  If  the  maximum  Ethernet  packet  size  was  chosen,  an  unnecessary 
network  dependence  would  be  introduced.  The  cost  of  application  buffer  management  is  considered  acceptable,  espe- 
cially since  it  is  incurred  only  on  reads. 

18  See  Chapter  5,  Section  A.  l.b(2)  for  more  information  on  these  functions 
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shared  memory  buffer.  Remaining  valid  data  is  shifted  into  the  low  order  positions  of  the 
data  area.  The  count  of  valid  bytes,  held  in  the  message  area,  is  decremented.  The 
shared  memory  buffer  now  appears  as  it  would  have,  if  it  had  only  received  the 
remaining  data  and  not  the  first  message  at  all.  As  long  as  only  entire  messages  are 
received  (one  or  more  at  a  time),  this  works  well.  When  the  TCP/IP  buffer  has  more  data 
than  the  data  area  can  take  at  one  time,  however,  the  receive  process  deposits 
LARGESTREAD  bytes  in  the  shared  memory  data  area.  It  is  highly  unlikely  that  this  will 
be  on  a  message  boundary. 

A  socket  read  overwrites  all  data  in  the  data  area.  A  partial  data 
reception  must  be  stored  and  concatenated  with  bytes  from  the  next  socket  read  to  get  a 
complete    message.     The   protocol   area    was    introduced    to    retain    the    protocol 

information19  required  to  decipher  the  variable  length  messages.  The  count  of  already 
received  bytes  of  a  message  is  held  here  between  socket  reads.  A  message's  protocol 
information  is  stored  here,  too.  Protocol  information  is  built  up  until  complete  (covering 
the  possibility  that  the  break  is  in  the  protocol  information  itself).  It  is  then  maintained 
until  the  entire  message  is  received  and  read  by  the  application.  The  buffering  works 

with  data  areas  as  small  as  four  bytes    . 

(2)  Broadcast.  The  datagram  socket  used  by  the  broadcast  protocol 
preserves  message  boundaries.  Each  recvfrom  call  to  a  socket  returns  only  one  message. 
This  message  must  be  no  longer  than  LARGESTREAD  bytes.  The  shared  memory  buffer 
management  routines  are  not  needed. 


19  See  Chapter  3,  Section  B.  1  for  a  description  of  the  protocol 

20  LARGESTREAD  must  be  specified  in  multiples  of  four  bytes.  The  smallest  possible  data  area  is  therefore 
four  bytes. 
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TCP/IP  keeps  unread  messages  on  a  queue.  This  queue  may  not  be  in 
sending  sequence.  If  the  queue  buffer  becomes  full,  subsequent  messages  are  lost 
[Ref.  21:  p.  8-8].  The  sending  buffer  can  easily  be  rilled  if  many  messages  are  broadcast 
in  a  short  period  of  time.  Each  broadcast  message  must  be  processed  by  every  host  on 
the  Ethernet.  Only  then  can  the  next  be  sent.  No  access  for  manipulation  of  the  TCP/IP 
sending  buffer  is  provided  because  its  size  is  normally  specified  during  system  generation 
and  is  not  easily  manipulated  by  an  application  program. 

2.  Silicon  Graphics.  Inc.  IRIS  3120 

There  are  no  required  changes  to  the  IRIS  2400-Turbo  code.  The  Makefile 
must  be  changed  to  remove  the  -Zf  compile  flag,  since  there  is  no  floating  point 
accelerator  board  in  this  machine. 

3.  Silicon  Graphics,  Inc.  IRIS  4D 

The  IRIS  4D  required  programming  changes  only  to  the  shared  memory 
module,  shareseg.c.  The  path  name  for  user  directories  is  also  different.  Changes  were 
necessary  to  the  Makefile  because  the  lusrlinclude  directory  structure  changed. 

The  IRIS  4D  is  based  on  the  MIPS  RISC  architecture.  The  UNIX 
implementation  was  done  differently  than  that  for  the  Motorola  68020.  Shared  memory 
segments  are  not  attached  to  addresses  within  the  data  section,  as  illustrated  in  Figure 
4.5.  They  are  attached  at  a  much  higher  address,  yet  accessing  them  does  not  result  in  a 
segmentation  violation.  This  is  a  more  robust  technique  that  obviates  any  manipulation 
of  attachment  addresses.  Multiple  shared  memory  segments  are  easily  attached,  using 
default  system  calls.  The  sharedsegment  call  suffices,  even  when  dynamic  memory 
allocation  is  needed.  To  maintain  backward  compatibility  for  application  code, 
dynamicsharedsegment  calls  sharedsegment,  ignoring  the  freespace  parameter,  when 
compiled  on  an  IRIS  4D,  and  calls  attach _within_datasegment  when  compiled  on  an 
older  IRIS  machine. 
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Figure  4.5     IRIS  4D  Default  Shared  Memory  Attachment 

C.     4.3BSD  UNIX 

The  netV.c  file  functions  properly  on  a  4.3BSD  machine  that  is  connected  to  only 
one  network.  The  start Jbroadcast  function  does  not  properly  handle  multiple  networks. 
The  other  functions  work  correctly,  even  when  the  machine  is  connected  to  multiple 
networks. 

All  other  functions  depend  upon  semaphores  and  shared  memory  for 
communication  between  the  spawned  processes  and  the  main  application.  Stream 
sockets21  could  be  used  to  provide  the  IPC  between  these  processes  under  4.3BSD.  The 


21  Unidirectional  stream  sockets  are  equivalent  to  pipes. 
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three  channels22  used  will  have  to  be  multiplexed  into  one,  but  the  implementation  is 
otherwise  straightforward. 

D.     LISP  MACHINES 

The  communication  code  is  a  flavor  to  be  mixed  with  the  application  [Ref.  11].  The 
Explorer  software  is  syntactically  equivalent  to  Genera  6  on  the  Symbolics.  With  a 
simple  change  in  the  sequence  of  method  and  flavor  names,  the  Genera  7  code  runs  on 
the  TI  Explorer.  The  older  flavor,  originally  developed  for  the  Explorer,  is  also  presented 
to  illustrate  working  directly  with  TCP/IP  instead  of  using  a  stream. 

1.      Texas  Instruments  Explorer  I 

This  older  flavor  works  with  Release  1.0  of  the  Explorer  TCP/IP  software.  It 
will  not  work  with  Release  2.0  as  the  implementation  was  changed  from  blocking  to 
non-blocking  [Ref.  27]. 

Messages  to  the  flavors  in  the  ip  package  are  made  together  with  messages  to 
the  tcp  flavors.  Network-independent  addressing  is  not  used.  Table  4.5  describes  the 
addressing  schemes  possible  [Ref.  28:  pp.  4-2 — 4-3].  Class  C  addressing  is  used  by  the 
Computer  Science  Department.  Figure  4.6  shows  the  simple  encapsulation  of  the 
addresses  for  irisl,  iris2,  and  iris3.  Extension  to  include  other  machines  is  easy. 

Table  4.5     INTERNET  ADDRESSING  CLASSES 


Class 

No. 
Networks 

No. 
Hosts 

A 

128 

16,777,216 

B 

16,384 

65,536 

C 

2,097,152 

256 

22  These  are  the  semaphore,  the  message  areas  of  the  shared  memory  buffer,  and  the  data  areas  of  the  shared 
memory  buffer.  The  first  is  unidirectional  from  application  to  spawned  process.  The  second  is  bidirectional  and  three 
state  (see  Table  4.3). 
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(defvar  * i ri s 1- address*  3221866502) 
(defvar  * i r i s2-address*  3221866504) 
(defvar  * i r i s3-addres s*  3221866505) 

(defvar  *des t -  address*   nil)  ;  the  tcp-ip  or  internet  address 

;  look  in  network  configuration 

(def un  iris  ( x ) 

(cond  ((equal  x  1)  (setq  *des t -address*  *i ri si -address* ) ) 

((equal  x  3)  (setq  *des t -addres s*  *i r i s3-address* ) ) 

(t  (setq  *dest -address*  *i r i s2-addres s*) )  )  ) 

Figure  4.6     Encapsulation  of  IRIS  Addresses 


A  port  is  acquired  by  using  the  :get-port  method  of  the  tcp-handler  flavor. 
Here,  shown  in  Figure  4.7,  we  use  the  global  instance,  *tcp-handler*23  to  create  specific 
instances  of  the  Transmission  Control  Block  (TCB)  for  each  of  the  two  ports.  Only  the 
client  side  of  the  server/client  paradigm  has  been  implemented.  The  client  is  created  by 
using  the  :active  mode  argument  to  the  :open  method  of  the  tcp-port  flavor.  Both  the 
sending  and  receiving  ports  are  full  duplex,  but  are  only  used  in  a  simplex  mode.  Figure 
4.8  shows  the  creation  of  the  sending  port  [Ref.  28:  pp.  4-12 — 4-18]. 

The  three  fields  in  a  message  are  sent  and  received  separately.  Each  field  is 
then  treated  as  a  separate  object.  Figure  4.9  illustrates  sending  a  message.  For  all  fields, 
the  urgent  argument  is  specified  as  nil.  The  push  argument  is  specified  as  nil  until  the 


(defvar  * tcp-handler 1*  (send  ip ::* tcp-handler*  :get-port)) 
(defvar  * tcp-handler2*  (send  ip : : *tcp-handler*  :get-port)) 

Figure  4.7     Lisp  Port  Acquisition 


The  double  :  allows  the  tcp-handler  to  be  found,  since  it  was  not  created  "exportable"  in  the  Ip  package. 
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(send  talking-port  :open 
: ac  t  ivc 

talking-port -number 

destination 


tcp  will  begin  the  procedure  to  establish 
connection   (default   vs   passive) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  tpassive  mode  local  machine  waits  for 
connec  t  ion 
set  max  seconds  before  read  request  times  out 


30  ) 

Figure  4.8     Opening  a  Lisp  Client  Connection 


(progn 

(send  talking-port  :send 
typebuf f er 
1 

nil 
nil  ) 
(if  (=  (length  lengthbuf f er )  4) 
(send  talking-port  : send 
lengthbuf fer 
4 

nil 
nil  ) 
(progn 

(loopfor  *  1 oopvar i nb 1 e*  (length  1 eng t hbuf f er )  4 
(send  talking-port  :send  "0"  1  nil  nil)  ) 
(send  talking-port  :send  lengthbuffer  (length  lengthbuf fer )  nil  nil)  )  ) 
(send  talking-port  : send 
buffer 

buffer  - 1 ength 
t 
nil  )  ) 

Figure  4.9    Sending  a  Message 


data  buffer  is  sent,  when  it  is  specified  as  t.  The  entire  message  is  thus  sent  as  a  unit  to 
the  other  machine. 

2.      Symbolics  36xx 

Genera  7  syntactic  conventions  are  followed.  The  principle  difference  with 
Genera  6  conventions  is  in  the  definethod  function.  In  Genera  6  (and  the  TI  Explorer), 
the  method  name  follows  the  flavor  name.  In  Genera  7,  the  method  name  precedes  the 
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flavor  name.  Figure  4.10  shows  the  difference.  It  also  shows  the  other  main  difference 
with  the  earlier  code,  that  streams  are  used.  The  use  of  streams  improves  portability  and 

eliminates  the  need  for  the   :reuse-iris  method24.  It  may  be  slightly  slower,  but  any 
difference  has  been  unnoticeable. 

Another  change  was  to  remove  the  dependence  on  hard-coded  addresses.  The 
method  :init-destination-host  was  added  to  the  conversation-wifh-iris  flavor  (see 
Figure  4.11).  By  using  the  net: parse-host  function,  the  application  need  only  know  the 
name  of  another  machine.  As  network  tables  are  updated,  no  change  to  the  application 
code  is  necessary  unless  a  different  machine  is  desired. 


(defmethod  (conversal ion-wilh- iris  :stop-iris) 

() 

(progn  (send  talking-port  :close) 
(send  listening-port  :close)  )  ) 

Genera  6 

(defmethod  (:stop-iris  conver sat ion-wi  th- i r i s  ) 
() 

(progn  (send  t a  Ik ing- s t ream  :close) 
(send  1 i s t ening- s t ream  :close)  )  ) 

Genera  7 
Figure  4.10    Genera  6  and  7  defmethod 


(defmethod  ( : ini t -des t ina t ion-hos t  conver sat ion-wi  th- i ri s ) 
(name-of -hos  t ) 
(setf  des t ina t ion-hos t -obj ec t  (ne t :par se-hos t  name-of -hos t ) )  ) 

Figure  4.11     Generic  Host  Addressing 


24  The  : reuse-iris  method  is  retained  for  backward  compatibility. 
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E.    Summary 

For  UNIX-based  machines,  generic  routines  are  developed  for  semaphore  use, 
shared  memory  use,  and  socket  use.  The  socket  routines  use  both  stream  sockets  and 
datagram  sockets  in  a  simplex  mode  to  provide  directly  connected  client/servers  and 
unconnected  broadcasting  communications.  IRIS  2400,  3120,  and  4D  systems  are  fully 
supported.  4.3BSD  systems  are  supported  with  mid-level  socket  calls  only. 

For  Lisp  machines,  stream-based  functions  are  available  for  direct  connection  as 
clients  only.  These  functions  are  available  directly  if  using  Genera  7  syntax  and  with 
minor  modification  if  using  Genera  6  syntax. 
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V.  USE  BY  APPLICATIONS 

A.  INTRODUCTION 

The  application  using  either  direct  connect  or  broadcast  protocol  is  not  concerned 
with  system-level  implementation  details.  Almost  all  aspects  of  shared  memory, 
semaphore,  and  socket  use  are  hidden.  The  number  of  other  machines  to  be  connected 
to,  the  use  of  dynamic  memory  allocation,  and  the  names  of  the  other  machines  are  all 
that  concern  the  application  in  setting  up  a  connection.  The  synchronization,  or  lack 
thereof,  in  communication  between  machines  is  a  design  decision,  not  a  protocol 
decision. 

B.  DIRECT  CONNECT 

A  UNIX-based  machine  can  be  either  a  server,  waiting  for  a  client  to  call  and 
establish  a  connection,  or  the  client.  A  Lisp  machine  is  always  a  client. 

1.      UNIX-Based  Machines 

The  functions  provided  for  UNIX-based  machines  are  all  written  in  C.  They 
must  be  linked  into  the  application  program  using  them.  Figure  5.1  is  an  example  make 
file  for  creation  of  an  application  program  on  an  IRIS  system. 

There  are  two  independent  processes,  send  and  receive,  that  are  spawned  to 
create  the  sockets  and  monitor  them.   They  are  made  separately  with  the   makefile 
contained  in  their  subdirectory. 


See  Appendix  A 
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CFLAGS  =  -Zg  -lm  -g  -p 

SHARE  =  /work/barrow/share3/ 

MAIN  =   cars  imu.c 

OBJS   =     First  group  of o  files 

OB  J  S 1    =  Second  group  of  .o  files 

OBJS2   =  Third  group  of  o  files 

OBJS3  =  $(SHARE)io_single.o  \ 
$  (  SHARE  )mp  a  t  h  .  o  \ 
$( SHARE) semaphore. o  \ 
$(SHARE)shareseg.o  \ 
$( SHARE) support .o 

OBJS4   =  Fifth  group  of  o files 

carsimu:  $(MAIN)  $(OBJS)  $(OBJSl)  $(OBJS2)  $(OBJS3)  $(OBJS4) 

cc  -o  carsimu  $(MAIN)  $(OBJS)  $(OBJSl)  $(0BJS2)  $(OBJS3)  $(OBJS4)  $(CFLAGS)  -Ibsd 

$(MAIN):  const. h  vars.h 

$(OBJS):  const. h  vars.h 

$(OBJSl):  const. h  objects. h 

$(OBJS2):  const. h 

$(SHARE)mpath.o:  $(SHARE) shared,  h 

cc  -c  -o  $<SHARE)mpath.o  $( SHARE )mpath . c  $(CFLAGS) 

$( SHARE) support .o:  $( SHARE) shared. h 

cc  -c  -o  $(SHARE) support .o  $( SHARE) suppor t . c  $(CFLAOS) 

$(SHARE)  semaphore  .  o  : 

cc  -c  -o  $( SHARE) semaphore. o  $ (SHARE) semaphore .c  $(CFLAGS) 

$(SHARE)io_single.o:  $( SHARE) shared. h 

cc  -c  -o  $( SHARE) io_s ingle. o  $(SHARE) io_s ingle . c  $(CFLAOS) 

$( SHARE) share seg.o; 

cc  -c  -o  $(SHARE)shareseg.o  $( SHARE) shareieg. c  $(CFLAOS) 

Figure  5.1     Sample  Application  make  File 


a.      Application  Setup 

The  server  process  must  be  started  first.  The  application  can  set  up  the 
communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response  to  a 
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specific  operator  command.  In  either  case,  there  will  be  two  messages  returned  to  the 
terminal  for  each  direct  connection  setup.  Figure  5.2  illustrates  a  normal,  single 
connection,  response.  Since  the  receive  and  send  processes  that  provide  the  messages 
are  independent,  the  two  lines  shown  may  be  jumbled.  A  variety  of  errors  can  occur  at 
this  point.  Table  5.1  gives  the  most  common  error  messages,  their  cause,  and  solution. 


Server  waiting    to   connect    to  name 
Server  waiting    to   connect    to  name 


Figure  5.2    Normal  Server  Response 


Table  5 . 1     SERVER  ERROR  RESPONSES 


Message 

Cause 

Solution 

Server  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

Server  couldn't  bind  address  to  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

slim  get:  Permission  denied 

The  shared  memory   seg- 
ment already  exists,  but  is 
owned  by  another  uid 

Change             key             in 
machinepath   call,  recom- 
pile, and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg- 
ment already  exists,  but  is 
too  small  because  the  value 
of   LARGESTREAD    has 
been  increased 

Run  rmshare  and  rerun  ap- 
plication 

shmat:  Permission  denied 

Someone  else's  send  or  re- 
ceive    process     is     being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used     in     shared. h,     for 
application's     include     of 
shared. h,           and           in 
application's         Makefile. 
Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.   If  some 
are      not,      get      updated 
modules  and  recompile — 
especially    send    and    re- 
ceive. 
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The  client  process  must  not  attempt  connection  until  after  the  server  is 
properly  running  (the  messages  in  Figure  5.2  have  been  received).  The  application  can 
set  up  the  communications  paths  as  part  of  initialization,  or  it  can  do  so  only  in  response 
to  a  specific  operator  command.  When  client  communications  setup  is  part  of  the 
initialization,  care  must  be  taken  to  wait  for  a  ready  server  before  starting  the  client.  In 
either  case,  there  will  be  two  messages  returned  to  the  terminal  for  each  direct 
connection  setup.  Figure  5.3  illustrates  a  normal,  single  connection,  response.  Since  the 
receive  and  send  processes  that  provide  the  messages  are  independent,  the  two  lines 
shown  may  be  jumbled.  A  variety  of  errors  can  occur  at  this  point.  Table  5.2  gives  the 
most  common  error  messages,  their  cause,  and  solution, 
b.      Coding  Practices 

(1)  Connection.  Making  a  connection  requires  two  acts.  The  first  is  to 
set  aside  space  for  the  data  required.  Figure  5.4  shows  this  code  when  local  declaration 
is  used.  The  Machine  structure  can  also  be  declared  globally.  The  second  is  to  request 
the  connection  with  a  machinepath,  dynamicmachinepath,  or  dynamicmachinepaths 
call.  Table  5.3  compares  the  three  types  of  call,  while  Figure  5.5  gives  a  server  example 
for  dynamicmachinepath,  A  description  of  the  parameters  used  is  in  Appendix  A, 
Section  2.  a. 

For  flexibility,  there  is  often  a  requirement  for  command  line 
specification  of  the  machine  to  be  connected  to.    For  ease  of  use,  there  is  often  a 


Connection  established  with  name 
Connection  established  with  name 


Figure  5.3    Normal  Client  Response 
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Table  5.2     CLIENT  ERROR  RESPONSES 


Message 

Cause 

Solution 

Client  couldn't  open  a  local  socket: 

Socket  in  use  due  to  previ- 
ous   run    not    terminating 
with  deletemachinepath 

Run  ps.    Use  kill  to  ter- 
minate any  receive  or  send 
processes  still  running 

Client  couldn't  connect  to  the  remote  server  socket: 

The  server  has  not  success- 
fully started 

The  port  numbers  used  by 
client  do  not  correspond  to 
those  of  server 

Terminate    client,    restart 
server,  restart  client  when 
server  started 

Correct,     recompile,     and 
rerun 

shmget:  Permission  denied 

The  shared  memory  seg- 
ment already  exists,  but  is 
owned  by  another  uid 

Change            key           in 
machinepath  call,   recom- 
pile, and  rerun 

shmget:  Invalid  argument 

The  shared  memory  seg- 
ment already  exists,  but  is 
too  small  because  the  value 
of   LARGESTREAD    has 
been  increased 

Run  rmshare  and  rerun  ap- 
plication 

shmat:  Permission  denied 

Someone  else's  send  or  re- 
ceive    process     is    being 
spawned 

Outdated  software  is  being 
used. 

Check  that  proper  path  is 
used     in     shared.h,     for 
application's     include     of 
shared.h,           and           in 
application's         Makefile. 
Correct  and  recompile. 

Ensure  that  all  modules  are 
the  most  current.    If  some 
are      not,      get      updated 
modules  and  recompile — 
especially    send    and    re- 
ceive. 

#inc lude  "/work/bar row/ share3/ shared.h" 
ma  in( argc , argv) 

y*»  +  +  %  +  **  +  ***  +  +  +  *******  +  *  +  ****  +  »*****  +  *:>%  +  *  +  +  *  +  ***  +  +  +  +  ***  +  **** 

LOCAL  DECLARATIONS 

**  +  **♦****♦•  +  **  +  +  *♦******  +  ****♦******  +  *****  +  ********♦*  +  ******  +  / 

Machine  cardriver;  /*  structure  for  coirmunica  t  ions  system  */ 


Figure  5.4    Creation  of  Machine  Structure 
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Table  5.3     PATH  CONNECTION 


Function 

Purpose 

machinepath 

Creates  a  link  between  two  machines 
No  subsequent  dynamic  memory  allocation  al- 
lowed 

dynamicmachinepath 

Creates  a  link  between  two  machines 
Subsequent  dynamic  memory  allocation  allowed 

dynamicmachinepaths 

Creates  a  link  between  two  machines 
Subsequent  dynamic  memory  allocation  allowed 
Multiple  calls  provide  multiple  links  to  one  or 
more  other  machines 

ma  in( argc , argv) 
/it*********************************************************** 

SYSTEM       INITIALIZATIONS 

ft***********************************************************/ 

/*  Open  up  the  net  path  to  other  machine  (iris3  default)  */ 
dynamicmachinepath( 2 , ot her_machine ,4, 5, "server"  ,&cardr i ver ,2000000) ; 


Figure  5.5     Server  Creation 


requirement  for  a  default  specification.  Figure  5.6  illustrates  one  way  to  accomplish  this 
for  a  client.  This  example  does  not  require  that  the  network  alias  be  defined  to  the 
system  as  it  uses  the  complete  address.  The  user,  however,  only  enters  the  alias. 

(2)  Program  Use.  The  simplest  high-level  communication  paradigm  is 
reading  from  and  writing  to  the  other  machine.  It  closely  parallels  handling  files  and 
terminals  in  C.  It  was  chosen  for  these  reasons. 

Twelve  high-level  functions  are  available.  Four  provide  status 
information,  four  write  to  other  machine,  and  four  read  from  other  machine.  Table  5.4 
describes  these  functions.  The  parameters  used  by  these  calls  are  described  in  Appendix 
A,  Sections  l.a  and  9.a. 
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main( a  rgc , argv) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 

I 

i^t****************************** ************  ***************** 

DATA         DECLARATION 

t************************************************************  / 

char  other_machine[50] ;  /*  name  of  other  machine  */ 

^^^•f^m******************************************************* 

SYSTEM  INITIALIZATIONS 

I*   pull    out    the    string    from   the    argument    list    */ 
i  f ( argc    >   2) 

I 

printf("NAV:  incorrect  argument  count!   use  nav  <alias>\n"); 
exit(l); 

) 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

if(  argc  ==  2  ) 

I 

strcpy(  other_machine ,  "npscs-"  ); 
strcat(  other_machine ,  argv[l]  ); 

} 
else 

strcpy(  other_machine ,  "npscs - i r i s2"  ); 

/*  Open  up  the  net  path  to  other  machine  (iris2  default)  */ 
dynamicmach i  nepa  th( 2 , ot  he  r_mach  ine ,5,4,"client"  ,&car ,2000000) ; 

Figure  5.6    Command  Line  Direction  for  Connection 


There  is  a  variety  of  ways  to  use  these  functions.  Figure  5.7 
illustrates  a  typical  scenario.  This  code  is  from  the  display  station  of  a  two-workstation 
driver  simulation.  The  display  station  provides  its  status  (that  of  the  "world")  on  each 
pass  through  its  graphical  display  loop.  The  control  station  must  read  that  status  on  each 
pass,  to  update  the  vehicle  position  on  its  track  diagram.  On  each  pass,  the  display 
station  checks  to  see  if  any  commands  have  been  received.  This  is  an  asynchronous 
communication,  as  the  display  station  continues  with  or  without  a  control  station 
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command.  The  asynchronous  reads  are  guarded  by  a  receiver _has_data  call  that  detects 
arrival  of  a  message.  Other  receiver  has  data  calls  are  used  to  "busy  wait"  for  the  next 
message.  In  practice,  it  has  not  been  necessary  to  include  any  but  the  first  "busy  wait" 
receiver  has  data  call.  TCP/IP  buffers  messages  when  they  are  not  immediately  read. 
It  then  blocks  them  into  the  largest  grouping  possible  and  delivers  them  when  the  next 
read  occurs.  The  LARGESTREAD  defined  constant  in  shared.h  determines  this 
maximum  grouping.  The  first  message  is  read  by  receive.  The  socket  is  then  ignored 
until  the  application  reads  the  data.  During  this  time,  the  other  messages  have  all  been 
sent  and  buffered  by  TCP/IP.  There  is  a  slight  delay  between  the  time  the  first  message  is 
read  and  the  block  containing  all  the  rest  is  read.  Thus  the  necessity  for  the  first  "busy 
wait"  receiver  has  data  call.  The  other  "busy  wait"  receiver _has_data  calls  are  simply 
for  robustness. 

The  "busy  wait"  sender  jsjree  call  determines  if  something  has 
happened  to  the  other  machine  or  Ethernet.  The  first  write  will  always  succeed,  as  it  goes 
to  a  buffer.   If  there  is  a  communications  problem,  TCP/IP  will  not  accept  it  and  the 

Table  5.4     COMMUNICATION  FUNCTIONS 


Function 

Action 

sender_is_free 

receiver_has_data 

received_type 

number  received 

Returns  TRUE  if  a  message  can  be  sent. 

Returns  TRUE  if  a  new  message  has  been  received. 

Returns    a   character  indicating   the   type   of  the   message.    CHARACTER.TYPB, 
INTEOERjrYPE,    and   FLOATTYPE    are   predefined.     CHARACTER_ARRAY_TYPE, 
INTEOER_ARRAY_TYPE,  and  FLOAT_ARRAY_TYPE  are  predefined 
Returns  an  integer  indicating  how  many  elements  in  message. 

write_character 
write_integer 
write_float 
write_characters 

Send  a  single  value  of  the  type  to  other  machine. 

read_character 
read_integer 
read_float 
read_characters 

Move  single  value  of  named  type  from  buffer  to  application  program  storage. 
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main( argc , argv) 


************************************************************* 


MAIN     SIMULATION     LOOP 

I************************************************************/ 

wh i I e ( veh i c 1 e . command . condi t ion  !=  DONE) 

I 

I************************************************************** 

Get  commands  (if  any)  from  navigator.   Commands  are  all  sent 
or  none  are  sent  so  no  information  is  needed  as  to  which  value 

i  s  wh  i  c  h . 

*********************** ***************************************^ 


if(  recei ver_has_dat a(  &cardriver  )  ) 

I 

read_i  n teger  (Ac  a rdr  i ver ,  &vehic le . command .condition); 
while(  ! receiver_has_data(  &cardriver  )  )  /*pr int f ( " 1" )*/ 

read_in teger (&c a r driver ,  Avehic le . conmand . brakepedal ) ; 
while(  ! receiver_has_data(  &cardriver  )  )  /*pr int f ( "2" )*/ 

read_in lege r(&car driver ,  &remot e_mousex) ; 

while(  I recei ver_has_data(  Acardriver  )  )  /*print f ( "3" )*/ 

read_float (Ac  a rdr i ver ,  Acmd  speed  ) ; 


I************************************************************** 

Report  all  status  information  to  navigator  every  cycle. 

************************************************************** ^ 

wri  te_floa t (&cardr  i ver ,  Aveh  icle.state_vector[l]) 

while(  ! sender_i s_f ree(&cardr i ver )  )  printf("b") 

wr  i  te_floa t (&ca  rdr i ver  ,  Avehic 1 e . s  t a t e_vec  tor [2] ) 

wr  i  t  e_floa  t  (&cardr  i  ver  ,  &vehicle  .  s  t  a  t  e_vec  tor  [3] ) 

wr  i  te_floa t (&ca  rdr i ver ,  &veh  icle. situation. distance_ traveled); 

wri  te_int eger (&c  ar driver ,  Avehic le . command. condi  t  ion) ; 

wr  i  te_int eger (&cardr i ver ,  Avehic le . command .brakepedal ) ; 

wr  i  te_in teger  (Ac  a rdr i ver ,  Avehic le.situation.lightcolor); 


}  /*  whi le  loop  */ 


}   /■ 


Figure  5.7     Synchronous  Write  /  Asynchronous  Read 
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sender jsjree  call  will  return  FALSE.  This  often  occurs  when  there  is  a  delay  by  the 
client  in  connecting  to  the  server  (the  display  station  here).  If  there  is  a  good  connection, 
TCP/IP  will  accept  and  buffer  all  input.  No  other  "busy  wait"  calls  are  needed.  The  other 
side  of  the  communication  is  shown  in  Figure  5.8. 

(3)  Disconnection.  Termination,  with  a  deletemachinepath  call  for 
each  path  opened,  is  mandatory.  If  not  performed,  the  sockets  (and  shared  memory 
segment  on  System  V  UNIX  machines)  will  not  be  returned  to  the  system.  Problems26 
may  then  occur  on  the  next  run.  Figure  5.9  is  an  example  termination  when  multiple 
paths  have  been  opened  [Ref.  11]. 
2.      Lisp  Machines 

All  necessary  functions  are  contained  in  a  single  file.  This  file  must  be  loaded 
before  use.  Figure  5.10  is  an  example.  A  Lisp  machine  is  always  a  client  and  is  started 
second.  Figure  5.11  illustrates  the  message  returned  with  a  successful  connection. 
Unsuccessful  connections  "hang"  and  return  nothing. 

a.      Connection 

The  address  of  the  server  and  the  ports  it  is  using  must  be  specified. 
Figure  5.12  shows  the  ports  specified  as  part  of  the  loaded  file.  When  using  the  older  TI 
Explorer  functions,  the  addresses  are  specified  in  the  same  way  (see  Figure  4.5)  and  then 
the  machine  desired  is  requested  by  number27  (shown  in  Figure  5.13).  When  using  the 
stream-based  functions,  the  addresses  are  not  specified  by  the  user  at  all.  The  network 
tables  are  accessed,  by  host  name,  through  the  select-host  function  provided  (shown  in 
Figure  5.14).   Once  the  instance  of  conversation-with-iris  flavor  has  been  completed 


24  Sec  Tables  5.1  and  5.2 

27  A  throwback  to  connection  only  with  different  IRIS  machines. 
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main( argc , argv) 


wh  i  1  e ( cond i t i on  !=  DONE) 

I 

^*m****************** ****************************************** 

Receive  all  status  information  from  car  every  cycle. 

**********************************+***************************/ 


while(  ! recei ver_has_da t a(  &car  ] 

1  ) 

read_floa  t  (Acar  ,  Acy); 

while(  ! receiver_has_dat a(  &car  ] 

) 

read_float  (&car ,  &cx); 

while(  ! receiver_has_dat a(  &car 

1  ) 

read_float (&car ,  &velocity); 

wliile(  !  receiver_has_dat  a(  &car  ' 

•  ) 

read_floa  t  (&car  ,  &rdistance); 

while(  1 recei ver_has_dat a(  Acar 

1  ) 

read_int eger  (Acar  ,  Acondition); 

while(  1 receiver_has_da t a(  &car 

1  ) 

read_in  t eger  (&car ,  &brakepos  i  t  ioi 

>); 

while(  ! receiver_has_da t a(  &car 

»  ) 

read_in t eger (&car ,  &1  ightcolor ) ; 

J *********************************************************+*+** 

Send  coitmands  (if  any)  to  car.   Commands  are  all  sent 

or  none  are  sent  so  no  information  is  needed  as  to  which  value 

is  wh i c h . 

*^********r******t.**t*****************************************^ 


i  f (any thing_h a s_c hanged) 

I 

any thing_has_changed  =  FALSE; 

wri te_integer(Acar ,  &condition); 

while(  I sender_i s_f ree(  &car  )  )  printf("a") 

wri  te_integer (fear  ,  &brakepos  i  t  ion) ; 

while(  ! sender_i s_f ree(  &car  )  )  printf("b") 

wri te_int eger (&car  ,  Amousex); 

while(  ! sender_i s_f ree(  Acar  )  )  printf("c") 

wr  i t e_floa t (Acar  ,  Acmdveloci t y ) ; 
J   /*  i f ( any th ing_has_changed)  */ 


}  /*  while  */ 


}  /*  main  */ 


Figure  5.8     Reciprocal  Synchronous  Read  /  Asynchronous  Write 
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del  e  t  emachinepa  th(&TI ) ; 
de le  t  emachinepa  t  h(&S\M3) ; 
de  1  e  t  emachinepa  t  h(&S"¥Ml )  ; 
dele t emachinepa th(&S~VM4) ; 

cxit(); 

} 

Figure  5.9    Connection  Termination 


;;;     this    is    the    conmunicat ion   package 
( load    " i  r i  sflavor" ) 


Figure  5.10     Loading  Lisp  Flavor 


"A  conversation  with  the  iris  machine  has  been  established" 

Figure  5.11     Lisp  Connection  Message 


(defvar  * i r i s 1 -por t 1*  1027)  ;  this  is  the  send  port 

(defvar  * i r i s 1 -por t 2*  1026)  ;  this  is  the  receive  port 

Figure  5.12    Setting  Port  Numbers  with  defvar 


;;;  get  the  network  going 

(iris  1) 

(setq  '"battle*'  (make- ins  t  ance  '  conver  sa  t  ion-wi  t  h- i  r  i  s  ) ) 

(if  (y-or-n-p  "start  networking  ?")  (send  *battle*  : s t ar t - i r i s  ) ) 

Figure  5.13     Specifying  Server  in  Lisp 
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(select -host    i  t  i  s2) 

Figure  5. 14    Specifying  Server  by  Name  in  Lisp 

with  port  numbers  and  host  addresses,  the  connection  is  established  with  the  method 
:start-iris,  see  Figure  5.13. 

b.  Program  Use 

The  method  :get-iris  returns  with  the  object  sent  by  one  message.  The 
method  (:put-iris  object)  sends  the  object  as  one  message.  Figure  5.15  illustrates  both. 
Note  how  methods  are  added  to  flavor  conversation-with-iris  to  simplify  the 
application  interface  even  further.  [Ref.  11] 

c.  Disconnection 

Disconnection  is  accomplished  with  the  method  :stop-iris,  shown  in 
Figure  5.16. 

C.      BROADCAST 

Only  UNIX-based  machines  support  our  broadcast  protocol  at  this  time.  It  is  a 
unidirectional  protocol,  but  nothing  prevents  the  establishment  of  two  unidirectional 
channels  in  opposite  directions.  Using  two  broadcast  channels  to  emulate  a  direct 
connect  channel,  however,  loads  all  other  machines  on  the  network  by  requiring  every 
other  machine  to  process  each  message.  It  is  also  less  reliable.  Broadcasting  is  good  for 
sending  status  information  to  many  other  machines,  as  long  as  those  machines  can 
tolerate  missing  reports. 

1.      Similarities  With  Direct  Connect  Protocol  Use 

Using  the  broadcast  protocol  is  similar  to  using  the  direct  connect  protocol. 
The  same  functions  are  used  in  the  same  way.  Each  connection  must  set  aside  space  as 


52 


defini t  ions  : 


obj  ec  t  :  "n" 
x 

y 

z 

spd 

dir 


name:  character  "1"  ..  "5" 

x  coordinate:  real 

y  coordinate:  real 

z  coordinate:  real 

speed:  real 

di  rec  t  ion :  real 


in  lisp   ("n"  (x  y  z  ipd  dir)) 


speed  of  vehicle  -10.00  to  25.00 
compass  dir  in  degrees  from  ON 


;;;  get  an  object  in  graphics  environment  (defined  as  above) 

(defmethod  (conver sat ion-wi  th- i r i s  :object) 
() 
(makeob j 


( send  self  :ge t  -  i 

( send  self  : ge t  - 

( send  self  :  ge  t  - 

( send  self  :  ge  t  - 

( send  self  : ge I  - 

( send  self  : ge  t  - 


ris) 
r  i  s ) 
ris) 
ris) 
ris) 
ris)  )  ) 


;;;  vision  returns  a  list  of  objects  in  the  tank's  field  of  vision  (100m  radius) 
;;;  this  is  effectively  an  association  list 

(defmethod  (conversat ion-wi  th- i r i s  :vision) 
( tank) 
(let  ((field  nil) 

(n-obj  ec  t  s  0)  ) 
(progn  (send  self  :put-iris  "V") 
(send  self  :put-iris  tank) 
(if  (equal  "V"  (send  self  :get-iris)) 

(progn  (setq  n-objects  (send  self  :get-iris)) 
(dot  imes 

(x  n-objects  field) 

(setq  field  (cons  (send  self  :object)  field))  )  ) 
(progn 

(print  "iris  did  not  respond  to  the  vision  coirmand  sent  from  ") 
(princ  "tank  ") 
(princ  tank)  )  )  )  )  ) 

Figure  5.15     Application  Communication  in  Lisp 


in  Figure  5.4.  The  same  criteria  for  using  a  specific  machinepath  call  apply  (see  Table 
5.3).  The  same  communications  functions  are  available  as  in  Table  5.4.  Each 
connection  must  be  terminated  as  in  Figure  5.9. 
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(if  (y-or-n-p  "stop  iris  connection  ?")  (send  *battle*  :stop-iris)) 

Figure  5.16    Termination  of  Communications  in  Lisp 

2.     Differences  With  Direct  Connect  Protocol  Use 
a.      Application  Setup 

The  broadcast  protocol  is  not  directly  modeled  as  a  server/client 
relationship.  The  broadcaster  broadcasts  to  whomever  is  prepared  to  receive.  The 
receiver  must  be  ready  and  so  must  be  started  first.  Since  the  broadcaster  is  more  similar 
to  the  server  in  a  server/client  model,  this  connection  order  seems  exactly  backward.  No 
error  will  result  if  the  broadcaster  starts  first,  messages  will  simply  not  be  received.  The 
receiver  message  is  shown  in  Figure  5.17.  The  broadcaster  message  is  shown  in  Figure 
5.18.  When  a  direct  connect  channel  is  also  required  between  the  same  two  machines, 
achieving  proper  startup  order  is  easy.  Establish  the  direct  connect  channel  first,  then  the 
soon-to-be  broadcasting  process  sends  a  message  telling  the  receiver  to  start  up.  Once 
started,  the  receiver  process  sends  a  message  permitting  the  broadcaster  to  start. 


ready    to   receive    from  broadcaster  name 

Figure  5.17     Normal  Receiver  Response 


Waiting  to  broadcast 

Figure  5.18     Normal  Broadcaster  Response 
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b.      Coding  Practices 

The  parameters  to  the  machinepath  family  of  functions  are  used 
differently  for  the  broadcast  protocol.  All  are  required  to  be  present,  but  some  are 
ignored  (see  Table  5.5).  Since  a  broadcast  channel  is  unidirectional,  the  receive  type 
application  calls  are  meaningless  to  the  broadcaster  (the  receiver  has  data  call  always 
returns  false).  The  sendjype  application  calls  are  meaningless  to  the  receiver  (the 
sender  is Jree  call  always  returns  false). 

D.    Summary 

Using  the  same  functions,  an  application  can  either  broadcast  or  directly  connect  to 
another  machine.  The  same  steps  of  setup,  connection,  use,  and  termination  are  common 
to  both  protocols.  Care  must  be  taken  in  the  timing  of  the  two  (or  more)  machines  setup. 
After  that,  an  application  merely  reads  or  writes  data. 
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Table  5.5     MACHINEPATH  PARAMETERS 


Parameter 

Function 

machinepath 

dynamicmachinepath 

dynamicmachinepaths 

nummachines 

N/A 

Number  of  channels  that  could 
be  created  by  application.  This 
includes   both  DIRECT  CON- 
NECT and  BROADCAST  chan- 
nels. 

segmentnum 

Arbitrary  integer.    Should  be  different  than  another 
user's  application. 

Only  first  call's  value  used. 

mname 

DIRECT    CONNECT    and    BROADCAST    {receiver 
only):  Name  of  machine  to  connect  to. 

BROADCAST  {broadcaster  only):  Required  but  ig- 
nored 

sendportnum 

DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  send  to  other  machine. 

BROADCAST  {broadcaster  only):  Number  (0-3076) 
of  port  to  be  used  for  broadcast. 

BROADCAST  {receiver  only):  Required  but  ignored 

receiveportnum 

DIRECT  CONNECT:  Number  (0-3076)  of  port  to  be 
used  to  receive  from  other  machine. 

BROADCAST  {broadcaster  only):  Required  but  ig- 
nored 

BROADCAST  {receiver  only):  Number  (0-3076)  of 
port  to  be  used  for  broadcast. 

server 

"server":             Create  DIRECT  CONNECT  channel 
as  a  server. 

"client":              Create  DIRECT  CONNECT  channel 
as  a  client. 

"broadcast":       Create  BROADCAST  channel  as  a 
broadcaster. 

"receive":           Create  BROADCAST  channel  as  a 
receiver. 

instructure 

Address  of  Machine  structure  created  to  hold  channel 
information. 

freespace 

N/A 

Amount  of  space  to  be  used  for 
dynamic  memory  allocation. 

Only  first  call's  value  used. 
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VI.  Performance 

A.    Introduction 

We  look  at  the  size  of  packets  from  our  protocols.  We  also  look  at  the  effect  of  real 
applications  on  the  network.  We  try  to  do  this  for  both  direct  connect  and  broadcast 
protocols.  However,  no  application  making  good  use  of  broadcast  protocols  exists. 
Hence,  we  used  a  direct  connect  test  application  and  replaced  the  channel  with  two 
broadcast  channels. 

B.      DATA  COLLECTION 

The  LANalyzer  EX  5500  network  analyzer  was  used  to  gather  Ethernet  statistics. 
Version  2.0  of  the  software  was  used.  The  LANalyzer  5500  is  a  COMPAQ  PORTABLE 

II  with  a  coprocessor  board  installed.  The  coprocessor  board  has  an  Intel  80286  CPU, 
an  Intel  82586  LAN  coprocessor,  and  two  MBytes  of  memory.  It  performs  packet 
collection,  packet  filtering,  and  network  statistics  calculation.  The  COMPAQ  PORTABLE 
II  processor  handles  user  software  control,  screen  updating  and  disk  I/O.  [Ref.  29] 

Samples  were  taken  while  direct  connect  applications  were  running  on  iris2  and 
iris3.  To  compare  direct  connect  protocol  with  the  broadcast  protocol,  test  programs 

were  used28.  Table  6.1  summarizes  the  information  collected.  These  programs  send  a 
character  string,  an  integer,  and  a  floating  point  number  in  a  rotating  sequence.  The 
messages  are  either  sent  to  the  machine  specified  on  the  command  line  or  are  broadcast 
to  all  machines  on  the  local  network  but  only  received  from  the  machine  specified. 


*  LANalyzer  is  a  registered  trademark  of  Excelan,  Inc. 

"  COMPAQ  PORTABLE  II  is  a  tradmark  of  the  COMPAQ  Computer  Corporation. 

M  See  programs  prog.c,  prog2.c,  gprog.c,  and  gprogl.c  in  Appendix  D. 
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Table  6.1 

DIRECT  CONNECT  VERSUS  BROADCAST  STATISTICS 

Run 
Number 

Direct  Connect 

Number        Ave         Max 

of          Packet       Test 

„    ,              Size        Load 
Packets        ,.       . 

{bytes)         (%) 

Broadcast 
Number        Ave 
of          Packet 

Packets 

(bytes) 

Max 
Test 
Load 

(%) 

1 

1031 

91 

.10 

9498 

69 

1.0 

2 

1047 

111 

.05 

9860 

69 

1.0 

3 

465 

96 

<.05 

4000 

68 

1.0 

4 

698 

95 

.05 

2556 

68 

1.0 

5 

334 

103 

.10 

1262 

68 

1.0 

The  visual  simulation  application  measured  was  a  modified  version  of  the  driving 
simulator  [Ref.  7].    Table  6.2  summarizes  the  information  collected.    This  data  was 

taken  during  the  day29.  The  application's  communication  code  is  shown  in  Figure  5.7 
and  Figure  5.8.  One  trip  around  the  track  took  approximately  five  minutes.  Seven 
messages  are  sent  every  cycle  to  report  status.  Four  messages  are  sent  in  the  opposite 
direction,  as  required,  to  control  the  car.  One  circuit  was  driven,  on  autopilot,  for  each 
test  run.  There  were  about  500  cycles  per  test.  Approximately  3600  messages  were 
generated  per  test.  The  number  of  packets  sent  was  less  than  half  of  this.  The  apparent 
discrepancy  exists  for  two  reasons.  First,  each  packet  sent  also  generates  an 
Table  6.2     APPLICATION  NETWORK  USE  STATISTICS 


Run 
Number 

Number 
of 

Packets 

Average 

Packet 

Size 

{bytes) 

Peak 

Network 

Load 

(%) 

Peak 
Test 
Load 

(%) 

Average 

Network 

Load 

(%) 

1 

3747 

89 

13 

.10 

.5 

2 

3297 

89 

11 

.15 

1.0 

3 

4152 

89 

15 

<.05 

.5 

4 

2848 

89 

17 

.15 

.9 

5 

22830 

89 

17 

.10 

.3 

29  At  night,  with  less  competition  for  network  resources,  the  results  were  similar. 
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acknowledgement  packet  in  return.  By  acknowledging  each  packet,  the  stream  socket 
guarantee  of  delivery  and  proper  sequence  is  met.  Second,  after  the  first  packet 
(containing  the  first  message)  is  received,  the  remaining  three  or  six  messages  are 
immediately  sent.  The  receiving  process  has  often  not  yet  handled  the  first  one.  The 
remaining  messages  are  combined  into  one  and  all  are  read  as  one  block.  This  reduces 
the  interchange  to  a  typical  total  of  four  packets  per  cycle,  two  with  data  and  two  for 
acknowledgement.  Similarly,  four  packets  are  usually  generated  whenever  the  navigator 
process  issues  a  command  sequence  to  the  car. 

An  evaluation  of  a  five- workstation  application  [Ref.  11]  was  also  made.  This 
application  used  three  Symbolics  (syml,  sym3,  and  sym4),  expl,  and  iris2  to  perform  its 
tasks.  Statistics  were  similar  to  the  other  application,  but  the  Symbolics  irisflavor.lisp30 
exhibited  some  problem  behavior.  It  sent  three  packets  for  every  message.  The  first 
packet  contained  the  type  field  only.  The  second  packet  contained  both  the  type  field 
and  the  length  field.  The  third  contained  the  entire  message.  If  a  second  message 
immediately  followed  the  first,  three  more  packets  were  sent,  each  adding  one  field  to  the 
previous  packet.  Only  one  acknowledgement  was  received,  as  all  packets  in  a  group  had 
the  same  identification  number. 

C.     DISCUSSION 

Attempting  to  use  broadcast  protocol  with  the  simple  test  programs  failed.  One 
problem  encountered  was  overflow  of  the  sending  buffer  within  the  TCP/IP  layers.  The 
rapidity  of  attempted  transmission  was  the  cause.  Higher  network  loading  exacerbated 
the  problem.  When  the  test  application  was  slowed  down  with  printf  calls  (and  the 
output  redirected  into  a  file)  the  buffer  could  keep  up  with  sending  requests.    Using 


30  See  Appendix  C 
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broadcast  protocol  within  a  graphics  display  loop  should  pose  no  problems  unless 
numerous  data  elements  are  transmitted  at  one  time. 

Without  acknowledgement  packets,  broadcasting  put  fewer  packets  on  the  network 
than  did  the  direct  connect  protocol.  When  overall  load  was  haevy,  some  were  lost.  This 
poses  a  serious  problem  for  visual  simulation  applications.  Without  an  elaborate 
application-level  protocol,  the  receiving  process  will  never  know  what  was  intended  to 
be  sent.  Since  only  one  data  object  is  transmitted  at  a  time,  labeling  the  data  objects  is 
difficult.  All  that  is  available  is  to  alternately  send  different  types  and,  after  checking 
the  type  received,  make  a  determination  of  the  likely  intent  of  the  sending  process.  If  a 
block  of  data,  containing  different  types,  could  be  sent  as  a  single  message,  the  decoding 
problem  would  become  one  of  simply  sequence  checking.  Missing  status  packets  can  be 
safely  ignored  in  many  situations.  At  most,  a  simple  averaging  algorithm  can  smooth 
any  discontinuities  caused  by  a  missing  packet.  Timestamping,  with  a  virtual  timestamp, 
of  each  packet  would  eliminate  the  averaging  requirement. 

The  Symbolics  stream  version  is  much  less  efficient,  in  terms  of  network 
utilization,  than  is  the  Explorer's.  It  still  functions  correctly,  with  no  noticeable  delay. 
As  the  amount  of  data  to  transmit  increases,  the  Symbolics  flavor  will  eventually  have 
noticeable  performance  degradation. 

The  interconection  of  five  machines  loads  the  network  only  slightly  more  than  does 
that  of  two.  The  limitation  will  be  from  the  process  swap  overhead,  not  the  network. 

D.     SUMMARY 

The  direct  connect  protocol  sends  fewer  packets  than  messages.  Half  of  the  packets 
sent  are  acknowledgements.  These  acknowledgements  provide  the  reliability  of  the 
direct  connect  protocol.  The  broadcast  protocol  sends  one  packet  for  each  message. 
These  packets  tend  to  be  smaller  than  those  for  the  direct  connect  protocol.    Until  a 
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mechanism  exists  to  bundle  several  messages  into  one  broadcast  packet,  the  broadcast 
protocol  is  of  small  value. 
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vn.  Conclusions  and  recommendations 

A.     LIMITATIONS 

There  are  two  primary  limitations.  First,  the  Lisp  and  C  functions  differ  at  the  user 
level.  This  was  done  to  allow  each  to  be  used  readily  by  programmers  "thinking"  in  their 
respective  language.  We  have  found  this  to  be  confusing  to  students  who  are 
inexperienced  in  both  languages.  Second,  there  is  no  simple  means  to  transmit  a  block  of 
data  or  an  entire  file.  Each  data  element,  unless  it  is  part  of  an  array  of  characters,  must 
be  sent  separately.  This  was  done  to  "hit  a  middle  ground"  between  a  complex 
facility — printf  function — and  low-level  system  calls.  As  long  as  only  the  direct  connect 
protocol  existed,  this  was  only  an  annoyance.  As  discussed  in  Chapter  6,  this  is  a 
critically  limiting  factor  for  the  broadcast  protocol. 

The  port  to  BSD  UNIX  systems  without  shared  memory  and  semaphores  was  not 
completed.  The  socket  handling  aspects  are  portable,  but  the  shared  memory  aspects  are 
interwoven  throughout  the  system.  The  difficult  part  of  the  porting  will  be  designing  the 
message-passing  protocol  for  the  pipe  between  the  application  and  the  send  and  receive 
processes,  as  discussed  in  Chapter  4.  Other  specific  limitations  include: 

•  no  broadcast  capability  for  Lisp  machines 

•  no  server  capability  for  Lisp  machines 

•  limited  communication  error  handling — no  signals  are  sent  from  the    send  or 

receive  processes  to  the  application  process  if  they  encounter  problems 

•  limited  read/write  error  handling — a  read  or  write  of  the  wrong  type  will  be 
attempted  and  usually  produce  garbage 

•  no  out-of-band  capability 

•  Symbolics  iris-flavor.Hsp  creates  three  packets  per  message 
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B.      FUTURE  RESEARCH  AREAS 

Implementation  of  the  missing  structure  data  type  is  one  key  area  in  which  more 
work  could  be  done.  The  most  straight-forward  solution  to  this  would  be  to  add 
messages  to  the  send  section  of  the  shared  memory  array  without  signalling  the  send 
process  to  send  it  until  the  entire  block  was  ready.  Such  a  solution  eliminates  any  need  to 
change  the  receiving  functions  at  the  cost  of  either  an  additional  sending  function  or  an 
additional  parameter  to  the  existing  send  functions.  The  additional  send  function  would 
be  a  push  function  and  the  existing  send  functions  would  be  modified  to  never  signal  the 
send  process  to  send.  That  would  be  left  to  the  new  push  function.  Adding  a  parameter 
to  each  send  function  would  allow  any  send  function  to  push.  While  in  some  respects 
simpler,  changes  to  any  application  sending  a  block  of  data  would  have  to  carefully 
monitor  which  send  function  actually  is  pushing. 

Creation  of  a  Lisp  flavor  that  mimics  the  UNIX  functions  would  prove  useful  to  C 
programmers  who  find  a  need  for  Lisp  modules  in  their  visual  simulation.  Adding  server 
and  broadcast  capabilities  would  increase  the  applicability  of  the  protocols  to  future 
visual  simulation  projects.  Functions  to  break  complex  Lisp  objects  into  simple  ones  and 
then  combine  these  into  a  single  message  are  necessary  for  the  broadcast  protocol.  The 
Symbolics  version  should  be  corrected  to  send  a  packet  only  at  message  boundaries. 

C.    Summary  and  Conclusion 

The  routines  described  herein  have  already  proved  useful  to  researchers  at  the  Naval 
Postgraduate  School.  With  Ethernet  loading  never  exceeding  one  percent,  these  routines 
are  efficient  enough  to  use  without  concern.  With  the  additions  mentioned  above,  the 
goal  of  an  easy-to-use  yet  powerful  system  will  be  reached. 
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APPENDIX  A  -  IRIS  MODULE  DESCRIPTIONS 

1.     iojsingle.c 

a.      Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application's  use  and 

functions  that  are  used  exclusively  by  them.  The  parameters  for  externally  accessible 

functions  are  described  below. 

i.      number  received 
number_received(    instructure    ) 

Machine  *ins t rue ture ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 

*/ 

ii.  read  character 

read_character ( instructure , char  act er_out ) 

Machine  *ins tructure;   /*  includes 

char  *ins true ture . segment    a  pointer  to  the  shared  segment  */ 
char  *character_out ;    /*  pointer  to  output  character  */ 

iii.  readcharacters 

read_characters( ins tructure, outarr ay, array size) 

Machine  '"instructure;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment  */ 
char  outarrayl];    /*  output  character  buffer  */ 
int  arraysize;      /*  the  number  of  characters  to  be  returned  */ 

iv.  readjloat 

read_f loat ( ins tructure, f loat_out ) 

Machine  * i ns t rue ture ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment  */ 
float  *float_out;    /*  pointer  to  output  float  */ 

v.      read  integer 

read_integer( instructure , integer_out ) 

Machine  *ins tructure  ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment  */ 
int  *integer_out ;    /*  pointer  to  output  integer  */ 
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vi.     received jype 

char  received_type(  instructure  ) 

Machine  *ins t ructure  ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 

*/ 

vii.  write jcharacter 
wri  te_character( ins tructure, character. in) 

Machine  *ins tructure ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 
int  ins tructure . sendsem    the  semaphore  to  the  sender  */ 

char  *character_in;    /*  pointer  to  input  character  */ 

viii.  write  characters 

wri  te_characters( ins tructure, inarr ay .array size) 

Machine  "'instructure;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 
int  ins tructure . receivesem    the  semaphore  to  the  receiver 
char  *inarray;    /*  input  character  buffer  */ 
long  arraysize;      /*  the  number  of  characters  input  */ 

ix.  write _float 

wri t e_ float ( instructure, float_in) 

Machine  ""instructure;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 
int  ins tructure . sendsem    the  semaphore  to  the  sender  */ 

float  *float_in;    /*  pointer  to  input  float  */ 

x.      write  integer 

wri  te_integer( instructure, integer_in) 

Machine  *ins tructure ;   /*  includes 

char  *ins tructure . segment    a  pointer  to  the  shared  segment 
int  ins tructure . sendsem    the  semaphore  to  the  sender  */ 
int  *integer_in;    /*  pointer  to  input  integer  */ 
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b.      Code  and  Description 


/***************************************************************************** 


TITLE 

MODULE 

VERSION 

DATE 

AUTHOR 


In t er -Computer  Communication  Package 

io_s  ingle . c 

3.0 

15  December  1987 

Theodore  H.  Barrow 


****************************************************************************** 

*  * 

*  HISTORY:  * 

* 
* 

* 


VERSION 
DATE 
AUIHOR 
DESC. 

VERSION 
DATE 
AUIHOR 
DESC. 

VERSION 
DATE 
AUIHOR 
DESC. 


1.0 

27  May  1987 
Theodore  H.  Barrow 


Originally  part  of  support. c.   Contains  the  documented  read    * 
and  write  calls  for  use  by  the  application  programmer.         * 

* 

2.0  * 

* 

21  October  1987  * 

* 

Theodore  H.  Barrow  * 


Modified  read  routines  to  use  a  global  array  to  manage  the 
possibility  of  a  partial  message  receipt. 

3.0 

15  December  1987 

Theodore  H.  Barrow 


Modified  read  routines  to  use  part  of  a  buffer  set  instead  of  * 

the  global  array  to  manage  the  reception  of  a  partial  message.* 

*******************%*******************%************************************** 

*  * 

*  RECORD  OF  CHANGES  * 

*  * 

♦Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  *      Change  Description  *    Modules    *Vers* 

***************** *i *********************************************************** 

*  *  *  *  *  *  * 

*  *  *  *  * 
*****************************************************************************/ 
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^include  "shared. h" 
#inc lude  "gl . h" 


/*  The  following  routine  copies  a  character  into  the  shared  segment. 

It  puts  the  type  CHARACTERJTYPE  in  the  first  byte  and  the 
length  0001  into  the  next  four  bytes. 

It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 

It  then  sends  a  wakeup  to  the  sender  program. 

It  uses  an  input  structure  since  called  by  main  program 
*/ 

wr  i  t  e_charac  ter(instructure,character_in) 

Machine  *  ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem    the  semaphore  to  the  sender  */ 

char  *charac t er_in;    /*  pointer  to  input  character  */ 

{ 

int  msgsize   =  5  +  CHARACTERS  I ZE ;    /*  size  of  message  */ 

char  *senderstart  =  ins t rue t ure->segment  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  ■  senderstart  -I-  9; 

long  *sentlength  =  (long  * ) ins t rue ture->segmen t  +  WSENDEROFFSET ; 

/*  insert  the  type  code  */ 
♦(senderstart  +  4)  =  CHARACTERJTYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sprintf ((senderstart  +  5),  "%04d" ,  CHARACTER_S I  ZE ) ; 

/*  move  the  data  bytes  */ 

memepy (da t as t ar t ,  charac t er_in ,  CHARACTER_S I ZE ) ; 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

•/ 

V( ins t rue ture ->s ends em) ; 

}    /*  wr  i t e_charac ter  */ 
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/*  The  following  routine  converts  an  integer  to  a  string  and  copies  it 
into  the  shared  segment. 
It  puts  the  type  INTEGERTYPE  in  the  first  byte  and  the  string  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

*/ 

write_integer(instructure,integer_in) 

Machine  *  ins t rue ture  ;   /*  includes 

char  *inst rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem     the  semaphore  to  the  sender  */ 

int  *integer_in;    /*  pointer  to  input  integer  */ 

{ 

char  int eger_s t r ing[20] ;   /*  string  for  integer  conversion  */ 

int  length;  /*  length  of  integer  string  */ 

int  msgsize;  /*  size  of  message  */ 

char  *senderstart  =  ins t rue t ure->segment  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  S  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  *sentlength  =  (long  *) ins t rue t ure->segment  +  WSENDEROFFSET; 

/*  convert  integer  to  string  */ 

sprintf(  integer_s t ring,  "%d  ,  *integer_in  ); 

/*  find  length  of  integer  string  and  thus  message  */ 
length  =  strlen(  int eger_s t r ing  ); 
msgsize   =  5  +  length; 

/*  insert  the  type  code  */ 
♦(senderstart  +  4)  =  INTEGER_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sprintf ((senderstart  +  5),  "%04d"  ,  length); 

/*  move  the  data  bytes  */ 

memepy (da t as t ar t  ,  in t eger_s t r ing ,  length); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V( ins  t  rue  t ure->sendsem)  ; 

}    /*  wr i t e_in t eger  */ 
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/*  The  following  routine  converts  a  float  to  a  string  and  copies  it 
into  the  shared  segment. 
It  puts  the  type  FLQAT_TYPE  in  the  first  byte  and  the  length 

(in  bytes)  as  an  integer  (in  string  format)  into  the  next  four  bytes 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

*/ 

write_float(instructure,float_in) 

Machine  *  ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture . sendsem     the  semaphore  to  the  sender  * / 

float  *float_in;    /♦  pointer  to  input  float  */ 

I 

char  f loat_s t ring[30] ;   /*  string  for  float  conversion  */ 

int  length;  /*  length  of  float  string  */ 

int  msgsize;  /*  size  of  message  */ 

char  *senderstart  =  ins t rue ture->segment  +  SEM>EROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  senderstart  +  9; 

long  '•'sent  length  =  (long  *  )  i  ns  t  rue  t  ure  ->segmen  t  +  WSENDEROFFSET ; 

/*  convert  float  to  string  */ 

sprintf(  f loat_s t ring ,  "%t"  ,    *float_in  ); 

/*  find  length  of  float  string  and  thus  message  */ 
length  =  strlen(  float_string  ); 
msgsize   =  5  +  length; 

/*  insert  the  type  code  */ 
♦(senderstart  +  4)  =  FLQVTTYPE; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
sprintf ((senderstart  +  5),  "%04d"  ,  length); 

/*  move  the  data  bytes  */ 

memepy (da t as t ar t ,  f loat_s t r ing ,  length); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 
*sentlength  =  msgsize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 
indicating  that  he  can  reuse  the  shared  segment. 

*/ 

V(  ins  t rue ture ->s ends  em) ; 

}    /*  wri te_f loat  */ 
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/*  This  routine  returns  the  type  of  data  received.  */ 

char  rece ived_type(  instructure  ) 

Machine  *  ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 
*/ 
( 

return(  *( ins t rue ture->segment  +  RECEIVEROFFSET  +  4)  ); 

} 
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/*  This  routine  returns  the  number  of  data  items  received.  */ 
nun>ber_rece  i  ved(  instructure  ) 
Machine  *  ins t rue ture ;   /*  includes 

char  *inst rue ture . segment    a  pointer  to  the  shared  segment  */ 

i n I  t  emp_  i  n  t ; 

char  *protocolhold    =  ins  t  rue  ture->segmen  t  +  PROTOO0LH0LDOFFSET ; 

long  *part received    =  (long  * )pro t ocolhold ; 

long  ♦receivedlength  =  (long  *) ins t rue t ure->segment  +  A&RECEIVEROFFSET; 

char  *receiverstart   =  ins t rue ture->segmen t  +  RECErVEROFFSET; 

/*  check  if  only  part  of  protocol  information  received  */ 

if(  *rece i vedl eng th  <  5) 

I 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  prot ocolhold ,  rece i vers t ar t ,  'receivedlength  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver( instructure->se  gme  n  t ) ; 

V(  ins  t  rue  t ure->recei vesem) ; 

while(  rece iver_i s_free( ins t rue ture->segment )  )  /*  wait  */  ; 

/*  copy  rest  of  protocol  data  into  holding  area  */ 
memcpy(  (protocolhold  +  *par t received  +  4),  ( receivers t ar t  +  4), 
(5  -  *par t received)  ); 

) 
else 

I 

/*  copy  protocol  data  into  holding  area  */ 
memcpy(  protocolhold,  rece i ver s t ar t ,  9); 

/*  initialize  *part received  so  it  can  be  used  later  */ 
♦par t rece ived  =  0; 
I 

/*  determine  the  length  of  the  received  integer  string  and  thus  message  */ 
sscanf(  protocolhold  +  5,  "%d"  ,  &temp_int  ); 

switch(  *(prot ocolhold  +  4)  ) 

I 

case  CHARACTER_TYPE: 

rcturn(  1  ) ; 

break; 
case  INTEGERJTYPE : 

return(  1  ) ', 

break; 
case  FLOATTYPE: 

return(  1  ) ! 

break ; 
case  CHARACTER_ARRAY_TYPE : 

return(  t emp_in t /CHARACTER_SIZE  ); 

break; 
case  INTEGER_ARRAY_TYPE: 

return!  t emp_int / INTEGER_SIZE  ); 

break; 
case  FLOAT_ARRAY_TYPE : 

return!  t emp_int /FLOAT_SIZE  ); 
I 
)       /*    number_rece i ved  */ 
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/*  The  following  routine  returns  a  character  from  the  shared  segment. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*l 

read_character ( instruc ture, char ac  ter_out ) 

Machine  *  ins t rue ture ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 

char  *charac ter_out ;    /*  pointer  to  output  character  */ 

( 

/*  temporary  storage  for  move  of  received  data  or  for  protocol  information 

when  partial  receipt  */ 
char  temp(LARGESTREAD]  ; 

char  *protocolhold    =  ins t rue ture->segmen t  +  PROT0CX)LH0LDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t received    =  (long  * )pro t ocol hold ; 

int  msgsize  =  5  +  CHARACTER_SIZE;    /*  size  of  message  */ 

char  *receiverstart   =  ins t rue ture->segmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  +datastart       =  recei ver s t ar t  +  9; 

long  Teceivedlength  =  (long  *)  ins  t  rue  ture->segmen  t  +  WECEIVEROFFSET; 

/*  check  if  first  part  of  protocol  information  is  missing  */ 
if(  *par t rece i ved  ==  0  ) 

I 

/*  check  if  only  part  of  protocol  information  received  */ 
if(  *rece i vedlengt h  <=  5) 

( 

/*  move  data  received  (as  well  as  length  field)  to  holding  area  */ 
memcpy(  pro t ocolhol d ,  recei ver s t ar t ,  *rece i vedlengt h  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver( ins  true  t ure->segment ) ; 

V(  ins  t  rue ture ->recei vesem) ; 

while(  receiver_is  f ree( ins t rue ture->segment )  )  /*  wait  */  ; 

) 
) 

/*  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  */ 
msgsize    -=  *par t recei ved; 
datastart  -=  *par t rece i ved; 

/*  move  the  bytes  */ 

memcpy(character_out ,  datastart,  CHARACTER_SIZE) ; 

/*  make  buffer  ready  for  next  read  */ 

reset  buffer(  rece i vedl eng t h ,  msgsize,  instructure,  datastart, 
CHARACTER_SIZE,  par t received,  recei ver s tar t  ); 

)    /*  read_charac ter  */ 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  returned  integer. 

It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*/ 

read_ integer (inslruciure, integer_out ) 

Machine  *  ins t rue t ure ;   /*  includes 

char  ♦inslruciure. segment    a  pointer  to  the  shared  segment  */ 

int  *in teger_out ;    /*  pointer  to  output  integer  */ 

( 

char  in t eger_s t r ingfLARGESTREAD] ;   /*  string  storage  for  received  data  */ 

char  *protocolhold    =  ins t rue ture->segmen t  +  PROTOOQLHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *pa r t rece i ved    =  (long  * )pro t ocolhold; 

int  length;  /*  length  of  integer  string  read  */ 

long  segment  length;  /*  length  of  data  of  partial  massage  */ 

int  msgsize;  /*  size  of  message  */ 

char  *receiverstart  =  ins t rue ture ->segmen t  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  recei ver s t ar t  +  9; 

long  *receivedlength  =  (long  *) ins t rue t ure->segment  +  WtECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t_prot ocol (  protocolhold,  par t recei ved,  recei vedl ength ,  recei ver s t art , 
instructure,  &length,  Amsgsize,  ftdatastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 

if(  * rece i vedl eng ch  <  msgsize  ) 

I 

get_data(  &segment 1 ength ,  rece i vedlength ,  pa r t rece i ved , 
int eger_s t r ing,  &datastart,  Amsgsize, 
receiver s t ar t ,  instructure,  &length); 

/*  convert  to  string  */ 

integer_s t ring [segment  length  +  msgsize]  =  '\0'; 

) 
else 

( 

/*  move  the  integer  string  bytes  */ 
memepy ( int eger_s t r ing ,  datastart,  length); 

/+  convert  to  string  */ 
integer_st ring[ length]  =  '\0'; 

I 

/*  convert  the  received  string  to  an  integer  */ 
sscanf(  integer_s t r ing ,  "%d"  ,  integer_out  ); 

/*  make  buffer  ready  for  next  read  */ 

rese t_buf f er (  recei vedlength ,  msgsize,  instructure,  datastart,  length, 
par t received,  rece i ver s t ar t  ); 

)    /*  read_integer  */ 
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/*  The  following  routine  converts  a  string  in  the  shared  segment 
into  the  user  supplied  float. 

It  frees  the  receiver  side  of  the  shared  segment  if  empty. 

It  then  sends  a  wakeup  to  the  receiver  program. 

It  uses  an  input  structure  since  called  by  main  program. 
*/ 

read_float(instructure, f loat_out ) 
Machine  *  ins t rue ture ;   /*  includes 

char  *ins true ture . segment    a  pointer  to  the  shared  segment  */ 

float  *f loa t_ou t ;    /*  pointer  to  output  float  */ 

( 

char  f loat_s t r ing [LARGESTREAD] ;   /*  string  storage  for  received  data  */ 

char  *protocolhold    =  ins t rue ture->segmen t  +  PROTOO)LHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *part received    =  (long  *)protocolhold; 

int  length;  /*  length  of  float  string  read  */ 

long  segment  length ;  /*  length  of  data  of  partial  massage  */ 

int  msgsize;  /*  size  of  message  +/ 

char  *receiverstart  =  ins t rue ture ->segment  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  receiver s t ar t  +  9; 

long  *receivedlength  =  (long  * ) i ns t rue t ure ->segmen t  +  AKRECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
ge t_prot ocol (  pro tocolhold,  par t received,  rece i vedl engt h  ,  recei ver s t ar t  , 
instructure,  &length,  Ansgsize,  &datastart  ); 

/*  check  if  only  part  of  data  has  been  received  */ 
if(  *reccivedlength  <  msgsize  ) 

I 

get_data(  &segment 1 engt h ,  rece i vedl engt h ,  par t received , 
f 1 oa t_s t ring ,  &datastart,  Amsgsize, 
rece i ver s t ar t  ,  instructure,  &length); 

/*  convert  to  string  */ 

float_8 t r ing[ segment  length  +  msgsize]  =  '\0'; 

} 

e  1  se 

{ 

/*  move  the  float  string  bytes  */ 
memepy ( f 1 oa l_s t r i ng ,  datastart,  length); 


/*  convert  to  string  */ 
float_s t ring[ length]  =  '\0'; 


/*  convert  the  received  string  to  an  float  */ 
sscanf(  f loat_s t r ing ,  "%f"  ,    float_out  ); 

/*  make  buffer  ready  for  next  read  */ 

rese t_buf f er (  recei vedlength ,  msgsize,  instructure,  datastart,  length 
par t recei ved ,  recei ver s t ar t  ); 

)   /*  read_float  */ 

74 


io_single.c 

/*  The  following  routine  copies  characters  from  an  array 
into  the  shared  segment . 
It  puts  the  type  CHARACTER_ARRAY_TYPE  in  the  first  byte  and  the 

array  length  (in  bytes)  as  an  integer  into  the  next  four  bytes. 
It  then  puts  the  total  size  at  the  top  of  the  shared  segment. 
It  then  sends  a  wakeup  to  the  sender  program. 
It  uses  an  input  structure  since  called  by  main  program 

•/ 

wr  i  te_c harac ters ( ins t rue ture , inarr ay, array size) 

Machine  *  ins t rue ture ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment 

int  ins t rue ture . receivesem     the  semaphore  to  the  receiver.  */ 

char  *inarray;    /*  input  character  buffer  */ 

long  arraysize;      /*  the  number  of  characters  input  */ 

( 

int  datasize  =  arraysize  *  CHARACTER_SIZE;  /*  size  of  data  field  */ 

int  msgsize   =  5  +  datasize;  /*  size  of  message  */ 

char  *senderstart  ■  ins t rue t ure->segmen t  +  SENDEROFFSET ; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  +datastart  =  senderstart  +  9; 

long  *sentiength  =  (long  * ) ins t rue ture->segmen t  +  W5ENDEROFFSET; 

/*  insert  the  type  code  */ 

♦(senderstart  +  4)  =  CHARACTER_ARRAY_TYPE ; 

/*  insert  the  length  IN  BYTES  of  the  input  data  */ 
spr in t f( ( sender s tar t  +  5),  "%04d",  ( int )da t as i ze) ; 

/*  move  the  data  bytes  */ 

memepy ( (dat as t ar t ) ,  inarray,  datasize); 

/*  copy  out  the  size  of  the  data  from  the  shared  segment  top  */ 

♦sentlength  =  5  +  datasize; 

/*  at  this  point,  we  send  a  wakeup  to  the  sender  program, 

indicating  that  he  can  reuse  the  shared  segment. 
*/ 
V(  ins  t  rue t ure->sendsem) ; 

}    /*  wr  i te_charac ter s  */ 
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/*  The  following  routine  copies  bytes  from  the  shared  segment 
into  the  user  supplied  array. 
It  frees  the  receiver  side  of  the  shared  segment  if  it  is  empty. 
It  then  sends  a  wakeup  to  the  receiver  program. 
It  uses  an  input  structure  since  called  by  main  program. 

*/ 

read_charac  ters(instructure,outarray,arraysize) 

Machine  *  ins t rue t ure ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 
char  outarray[];    /*  output  character  buffer  */ 
int  arraysize;      /*  the  number  of  characters  to  be  returned  */ 

I 

char  +protocolhold    =  ins t rue ture->segmen t  +  PROTCXXHLHOLDOFFSET ; 

/*  first  four  bytes  of  holding  area  as  integer  */ 
long  *par t rece i ved    =  (long  * )prot ocolhold; 

int  length;  /*  length  of  character  string  read  */ 

long  segment  length;  /*  length  of  data  of  partial  massage  */ 

int  datasize  =  arraysize  *  CHARACTER_SIZE;  /*  size  of  requested  data  field  */ 

int  requestsize;  /*  size  of  message  */ 

int  msgsize   =  5  +  datasize;  /*  size  of  requested  message  */ 

char  *receiverstart  =  ins t rue ture->segment  +  RECEIVEROFFSET; 

/*  the  +  9  is  to  skip  over  the  first  4  bytes  for  the  size 

of  the  shared  memory  data  and  the  5  bytes  of  header  information  */ 
char  *datastart  =  receivers  tar t  +  9; 

long  *receivedlength  =  (long  *) ins t rue t ure->segment  +  WECEIVEROFFSET; 

/*  determine  proper  protocol  info  and  reset  variables  if  necessary  */ 
get_prot ocol (  pro tocolhold ,  par t received,  recei vedleng I h ,  recei ver s t ar t , 
instructure,  &length,  <5snsgsize,  &datastart  ); 

/*  check  if  all  of  data  (or  more)  was  requested  */ 

if(  length  <=  arraysize  ) 

{ 

/*  check  if  only  part  of  data  has  been  received  */ 
if(  * rece i vedlengt h  <  msgsize  ) 

{ 

get_data(  Asegmen t 1 eng th ,  rece i vedlength ,  par t recei ved , 
outarray,  &datastart,  &msgsize, 
recei ver s t ar t ,  instructure,  &datasize  ); 

) 
else 

{ 

/*  move  the  character  bytes  */ 

memepy (out  array ,  datastart,  length); 
I 


) 


/*  make  buffer  ready  for  next  read  */ 

rese t_buf f er (  recei vedl ength ,  msgsize,  instructure,  datastart,  datasize, 
par t recei ved,  recei ver s t ar t  ); 
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e  1  se 
I 


) 


/*  move  the  bytes  */ 

memcpy ( ou t array ,  datastart,  datasize); 

/*  make  buffer  ready  for  next  read  */ 

reset_buf fer (  rece i vedlength ,  msgsize,  instructure,  datastart,  datasize, 
par t received,  receivers  tar t  ); 

/*  read_charac t er s  */ 
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/*  These  are  various  support  routines  used  by  several  of  the  preceding 
f unc  t  ions . 

*/ 

rese t_buf f er( rece i vedleng th ,  msgsize,  instructure,  datastart,  datasize, 
par t recei ved ,  receiver s t ar t ) 

long  ♦recei vedlength ;   /*  first  four  bytes  of  receive  part  of  shared  seg  */ 

int  msgsize;  /*  size  of  message  read  ♦/ 

Machine  *  ins t rue t ure ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment 

int  ins t rue ture . receivesem     the  semaphore  to  the  receiver.  */ 

char  ♦dat as t ar t ;        /*  address  data  starts  in  receive  part  of  shared  seg  */ 

int  datasize;  /*  length  of  data  part  of  message  ♦/ 

long  *par t rece i ved;     /*  length  of  message  received  in  previous  block  */ 

char  ♦recei vers t ar t ;    /♦  address  receive  part  of  shared  seg  starts  */ 

I 

char  temp[LARGESTREAD] ;   /♦  temporary  storage  for  move  of  received  data  ♦/ 

/*  free  the  receiver  segment  if  this  is  only  message  received  */ 
i f( ♦recei vedleng th  ==  msgsize) 

{ 

free_receiver(instruc  t ure->segmen t ) ; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
indicating  that  he  can  reuse  the  shared  segment. 

•/ 

V(instructure ->recei vesem) ; 

) 

else     /♦  shift  data  forward  in  shared  memory  segment  */ 

( 

♦recei vedlength  -=  msgsize; 

memcpy(temp,  (datastart  +  datasize),  (LARGESTREAD  -  msgsize)); 

memepy (( rece i vers t ar t  +  4),  temp,  (LARGESTREAD  -  msgsize)); 

) 

/*  reset  ♦par t rece i ved  for  next  read  */ 
♦par t rece i ved  =  0; 

}    /♦  reset_buffer  ♦/ 
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get_protocol (  protocolhold,  par t received ,  recei vedlength ,  receiver  star t , 
instructure,  length,  msgsize,  datastart  ) 

char  ♦protocolhold;     /♦  protocol  holding  area  ♦/ 

long  *par t received;     /♦  length  of  message  received  in  previous  block  ♦/ 

long  ♦receivedlength ;   /♦  first  four  bytes  of  receive  part  of  shared  seg  ♦/ 

char  ♦receivers  tar t ;    /*  address  receive  part  of  shared  seg  starts  */ 

Machine  *  ins t rue ture ;   /♦  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment 

int  ins t rue ture . receivesem     the  semaphore  to  the  receiver.  ♦/ 

int  ♦length;  /*  length  of  data  field  in  message  ♦/ 

int  ♦msgsize;  /♦  length  of  message  */ 

char  ♦♦datastart;       /*  address  data  starts  in  receive  part  of  shared  seg  */ 

/♦  check  if  first  part  of  protocol  information  is  missing  ♦/ 
if(  ♦par t recei ved  ==  0  ) 

/♦  check  if  only  part  of  protocol  information  received  ♦/ 
if(  ♦receivedlength  <=  5) 

I 

/♦  move  data  received  (as  well  as  length  field)  to  holding  area  ♦/ 
memcpy(  protocolhold,  recei vers t ar t ,  *recei vedlength  +  4  ); 

/*  get  next  message(s)  */ 

free_receiver(inst  rue ture- >segment ) ; 

V( ins t  rue ture- >receivesem) ; 

while(  receiver_i s_f ree( ins t rue ture->segmen t )  )  /♦  wait  */  ; 

/♦  copy  rest  of  protocol  data  into  holding  area  ♦/ 
memcpy(  (protocolhold  +  ♦par t recei ved  +  4),  ( recei vers t ar t  +  4), 
(5  -  ♦par t received)  ); 

I 
else 

I 

/♦  copy  protocol  data  into  holding  area  ♦/ 
memepyl  protocolhold,  rece i ver s t ar t  ,  9); 

/*  initialize  *part received  so  it  can  be  used  later  */ 
♦par  t  received  =  0; 


/+  determine  the  length  of  the  received  data  string  and  thus  message  ♦/ 
sscanf(  protocolhold  +  5,  "%d" ,  length  ); 
♦msgsize   =  5  +  ♦length  -  *par t rece i ved; 

/♦  reset  datastart  to  compensate  for  possible   partial  receipt  ♦/ 
♦datastart  -=  ♦part  received; 

)    /*  get_protocol  ♦/ 
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get_data(  segmen t 1 ength ,  recei vedlength ,  par t received,  s t r ing_ar ray , 
datastart,  msgsize,  recei vers t ar t ,  instructure,  datasize  ) 


long  ♦segmen t 1 engt h ; 
long  *rece i vedlength ; 
long  ♦par t recei ved; 
char  s t r ing_ar ray [ ] ; 
char  ♦♦da  t  as  t  ar  t  ; 
int  ♦msgsize; 
char  *rece i ver s t ar t  ; 
Machine  ♦instructure; 


/♦  length  of  partial  data  */ 

/*  first  four  bytes  of  receive  part  of  shared  seg  */ 

/*  length  of  message  received  in  previous  block  ♦/ 

/*  storage  for  incoming  characters  */ 

/*  address  data  starts  in  receive  part  of  shared  seg  */ 

/♦  length  of  message  ♦/ 

/♦  address  receive  part  of  shared  seg  starts  ♦/ 

/*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment 
int  ins t rue ture  .  recei vesem     the  semaphore  to  the  receiver.  ♦/ 


int  *dat as i  ze ; 
I 


/*  length  of  data  field  in  message  ♦/ 


/♦  determine  length  of  data  that  has  been  received  */ 
♦segment  length  =  ♦recei vedl eng th  -  5  +  ♦par t recei ved; 

/*  copy  the  first  segment  of  data  to  holding  array  ♦/ 
memc py(  s t r ing_array ,  ♦datastart,  ♦segmen t length  ); 

/♦  reset  msgsize  and  datastart  to  correspond  to  partial  receipt  ♦/ 
♦msgsize    -=  ♦segmen t 1 ength  +  5  -  ♦par t recei ved; 
♦datastart   =  recei ver s t ar t  +  4; 

/♦  get  next  message(s)  ♦/ 

free_receiver(instruc  t ure->segment ) ; 

V(instruc  ture->recei vesem)  ; 

while(  recei ver_i s_free( ins t rue ture->segment )  )  /♦  wait  ♦/  ; 

/♦  cycle  through  as  many  messages  as  it  takes  ♦/ 
while(  ♦rece i vedlength  <  ♦msgsize  ) 

/♦  copy  the  next  segment  of  data  to  holding  array  ♦/ 

memcpy(  &s  t r ing_ar ray [♦segment  length] ,  ♦datastart,  ♦recei vedlength  ); 

/♦  reset  msgsize  and  segmen t I ength  to  correspond  to  partial  receipt  ♦/ 
♦msgsize        -=  ♦recei vedlength ; 
♦segment  length  -=  ♦recei vedlength; 

/♦  get  next  message(s)  ♦/ 

free_receiver(instruct  ure->segment ) ; 

V(instruc  ture->recei vesem) ; 

while(  receiver_i s_f ree( ins t rue t ure ->segmen t )  )  /♦  wait  ♦/  ; 

) 

/♦  copy  the  last  segment  of  data  to  holding  array  ♦/ 

memcpy(  &s  t  r  ing_array  [♦segment  length]  ,  ♦datastart,  ""msgsize  ); 

/♦  reset  datasize  to  properly  reflect  last  segment  size  ♦/ 
♦datasize  =  ♦msgsize; 

)    /*  get_data  ♦/ 
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2.      mpath.c 

a.      Calling  Protocols 

All  functions  in  this  module  are  meant  to  be  accessible  by  the  application. 
These  functions  set  up  and  tear  down  the  communications  path  between  two  machines. 

i.      deletemachinepath 

dele t emachinepath( instructure) 

Machine  *inst rue ture;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  shared  segment, 
int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number, 
int  ins t rue ture . receivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 
*l 

ii.     machinepath 

machinepath( segment  num.  mname , sendpor tnum, recei vepor tnum, server, instructure) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mname[];      /*  machinename  character  string  */ 

long  sendpor tnum,  recei vepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server[];     /*  this  character  string  is  either  "client"  or  "server". 

It  indicates  whether  the  sender /recei ver  should  open 

up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server. 

•/ 

Machine  *  ins t rue ture ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *ins t rue ture . segment  --  returned  ptr  to  the  snared  segment, 
int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 
int  ins t rue ture . receivesem  --  the  returned  receive  semaphore. 
*/ 

iii.    dynamicmachinepath 

dynami  cmach i nepa th( seamen tnum, mname , sendpor  tnum, recei vepor  tnum, server , 
instructure, freespace) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 
char  mname[];      /*  machinename  character  string  */ 

long  sendpor tnum,  rece i vepor tnum;    /*  send  and  receive  port  numbers  */ 
char  server[];     /*  this  character  string  is  either  "client"  or  "server". 
It  indicates  whether  the  sender /recei ver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server. 

•/ 

Machine  '"instructure;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  snared  segment, 
int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 
int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  i t  on  the  send  portnumber. 
int  ins t rue ture . rece ivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 

•/ 

int  freespace;    /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 
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iv.    dynamicmachinepaths 

dynami  cmach  i  nepa  t  lis  (nuranach i nes  ,  segmen  t  num,mname  ,  sendpor  t  num.  rece  i  vepor  tnum, 
server, instructure, freespace) 


int  nurrmachines ;  /*  the  ma 
long  segmentnum;  /*  the  ke 
char  mname  | ] ;  /*  machin 
long  sendpor tnum,  recei vepor 
char  server[];  /*  this  c 
It  indi  ca 
up  as  ei  t 


must  be  t 


7 


ximum  number  of  other  machines  to  be  attached 
y  to  use  for  the  created  shared  segment  */ 

ename  character  string  */ 

tnum;    /*  send  and  receive  port  numbers  */ 

haracter  string  is  either  "client"  or  "server' 

tes  whether  the  sender /recei ver  should  open 

her  a  client  or  server.  The  first  guy  open 
he  server. 


Machine  *ins t rue ture ;    /* 
char  *  ins  t  rue  t ur 
int  ins  t  rue  t ure . 
int  instructure. 


structure  to  hold  segment  and  semaphore  info: 
e. segment  --  returned  ptr  to  the  shared  segment, 
shmid  --  returned  system  generated  shared  mem  id 
sendsem  --  the  returned  send  semaphore. 

We  base  i t  on  the  send  portnumber. 
int  ins t ructure. receivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 


int  freespace;     /*  amount 
after  this  rout  ine 

b.      Code  and  Description 


of  freespace  desired  for  dynamic  memory  allocation 
has  been  called.  */ 


J**************************************************************************** 

*  TITLE 

*  MXULE 

*  VERSION 

*  DATE 

*  AUTHOR 

***************************************************************************** 

* 


Int er -Computer  Communication  Package 

mpa t h . c 

5.0 

31  May  1988 

Theodore  H.  Barrow 


* 

HISTORY: 

* 

* 

VERSION 

* 

* 

DATE 

+ 

* 

AUIHOR 

+ 

* 

DESC. 

* 

* 

* 

VERSION 

* 

* 

DATE 

* 

+ 

AUIHOR 

* 

* 

DESC. 

+ 

* 

VERSION 

* 

+ 

DATE 

* 

* 

AUIHOR 

* 

* 

DESC. 

1.0 

6  February  1987 

Michael  J.  Zyda 

Contains  routines  machinepath  and  dele t  emachinepat h  for 
link  creation/removal  at  a  high  level  of  abstraction. 

2.0 

27  May  1987 

Theodore  H.  Barrow 

Converted  to  use  a  structure  for  ease  of  use. 

3.0 

21  October  1987 

Theodore  H.  Barrow 

Added  function  dynami cmachinepath  to  allow  dynamic  memory 
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allocation  after  conmunicat ions  link  established. 

VERSION:  4.0 

DATE    :  15  December  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Added  function  dynami cmachi nepa t hs  to  allow  use  with  multiple 
links.   Modified  all  creation  routines  to  place  sequence 
numbers  at  end  of  command  line  for  send  and  receive  processes. 

VERSION:  5.0 

DATE    :  31  May  1988 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Added  broadcast  and  receive  capability  -  one  process  spawned 

tit************************************************************************* 

RECORD  OF  CHANGES 

Version*   Date   *   Author  *  *   Affected    *Reqd 

*  Change  Description  *   Modules    *Vers 

*  *  *  *  * 

*  *  * 
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#include  "shared. h"    /*  my  special  defines  */ 
#include  <gl . h> 

dele t  emachi nepa t h( instructure) 

Machine  *  ins t rue t ure ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue t ure . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 

int  ins t ructure . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  ins t rue ture . receivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber 
*/ 
( 

/*  kill  the  receiver  process...  */ 

kill_receiver( ins  true ture -> segment , ins  true  ture-> receives em) ; 

/*  kill  the  sender  process...  */ 

kill_sender(instruc  ture->segment , ins  t  rue ture ->s ends  em) ; 

/*  detach  and  delete  the  shared  segment...  */ 

del e  tesharedsegment (instruc  ture->segment , ins  t  rue ture->shmid) ; 


84 


mpath.c 

/• 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  machinepath  routine  performs  the  following: 

(1)  creates  a  shared  segment. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbers. 

(3)  free_sender( segment )  and/or  f ree_receiver( segment ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  server/c 1 ient /broadcas t  0&"  ) ; 
sys tem( " receive  sharedseg#  machinename  port#  server/c 1 ient /receive  0&"  ) ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

•/ 

machinepa th( segmentnum.mname  , sendpor tnum,  rece ivepor tnum,  server,  ins t rue ture) 

long  segment num;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mname[J;      /*  machinename  character  string  */ 

long  sendpor tnum,  receivepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server[  j  ;     /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sender /receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.   If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
♦/ 

Machine  *  ins t rue t ure ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue ture . sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  portnumber. 

int  ins t rue ture . receivesem  --  the  returned  receive  semaphore. 
*/ 
( 

char  * sharedsegmen t  (  ) ;       /*  shared  segment  creation  function  */ 

int  semtran();  /*  semaphore  creating  routine.  */ 

char  temp [200],  temp2[200];  /*  temp  character  arrays  */ 

/*  create  the  shared  segment  */ 

ins  t  rue  t ure->segment  =  shared segment ( segment num .MAXSHAREDSIZE.&ins t  rue  ture->shmid) ; 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
ins t rue ture->sendsem  =  semt  ran( sendpor tnum) ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
ins t rue ture->receivesem  =  semt  ran( receivepor tnum)  ; 

/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini  t_shared_buf f er ( ins  t  rue  ture->segment ) ; 

/*  spawn  off  the  sender  process  */ 

if(  strcmp(  server,  "receive"  )  1=  0  ) 
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/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
strcpy(  temp.SEMMjOCATION); 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  number  of  the  sharedsegmen t  in  text  */ 
spr int  f ( temp2,  "%d" , ins  t  rue  t u re ->shmi d) ; 
strcat(t  emp, t emp  2) ; 
s treat (temp,"  "); 

/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp.mname  )  ; 
strcat(t emp , "  " ) ; 

/*  add  the  port  number  */ 

spr  int  f ( t emp2, "%d" , sendpor  tnum)  ; 

s  t  rca t ( t  emp, t emp2) ; 

st rcat ( temp, "  "); 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  rca  t ( t  emp, server ) ; 
s  t  r  c  a  t ( t  emp , "  0 " ) ; 

/*  spawn  off  into  the  background  */ 
s  t  r  c  a  t ( t  emp , "A"  ) ; 


/  + 

if 

} 
else 

I 

/* 


ki 


spawn  off  the  sender  */ 
(  system(temp)  ==  - 1  ) 
perror  (  "SEW  system  call  failed"); 


kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  rece i ver_has_dat a( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 
ll_sender(  ins t rue ture->segment ,  ins t rue ture->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 
if(  strcmp(  server,  "broadcast"  )  !=  0  ) 


( 


/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 


s  t  rcpy 
s  t  rcat 

/*  add 


spr  int  f( t  emp 2 , "%d" , ins t rue ture->shmid) ; 


3  t  rca  t 
8  t  rcat 

/*  add 
s  t  rca t 
s  t  rca t 

/*  add 


s  t  rca t 
s  t  rca t 

/*  ind 
s  t  rca  t 
s  t  rca t 


t  emp , RECE IVELOCAT ION) ; 
temp,"  "); 

the  number  of  the  sharedsegment  in  text  */ 


t  emp ,  t  emp2 ) ; 
temp,"  "); 

on  the  machine  name  +/ 
t  emp  ,mname  )  ; 
emp ,    ) ; 

the  port  number  */ 


spr  int  f( t  emp 2 , "%d" .receivepor  tnum)  ; 


t  emp , t  emp 2 ) ; 
temp,"  "); 

cnte  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
temp, server ) ; 
temp,"  0"); 


/*  spawn  off  into  the  background  */ 
s treat ( temp, "&") ; 
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/*  spawn  off  the  receiver  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  - 1  ) 

perror( "RECEIVE  «y«tem  call  failed") 
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/* 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  dynamicmachinepath  routine  performs  the  following: 

(1)  creates  a  shared  segment  and  attaches  it  to  the  main  program  virtual 
space  after  an  allocation  of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbers. 

(3)  free_sender( segment )  and/or  free_rece iver( segment ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

sy s t em(  " send  sharedseg#  machinename  port#  server /c 1 ient /broadcas t  0&"  ) ; 
sys t em(  " rece ive  sharedseg#  machinename  port#  server /cl ient /receive  0&"  ) ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 

Machine  that  is  declared  in  the  calling  program. 
•/ 

dynami  cmach  i  nepa  t  h( segment num.mname  , sendpor tnum,  rece iveport num.  server , 
ins  t  rue  t  tire,  free  space) 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mname [ ] ;      /*  machinename  character  string  */ 

long  sendpor t num,  receivepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server!];     /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sender /receiver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.   If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
*/ 

Machine  *  ins t rue t ure  ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue ture . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue ture. sendsem  --  the  returned  send  semaphore. 

We  base  it  on  the  send  port  number. 

int  ins t rue ture . receivesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 
*/ 

int  freespace;     /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 

i 

char  *dynanii  c sharedsegmen t (  )  ;    /*  shared  segment  creation  function  */ 

int  semtranO;  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];      /*  temp  character  arrays  */ 

/*  create  the  shared  segment  */ 

ins  t  rue  ture->segmen  t  =  dynamic sha redsegmen  t  (  1  ,  segmentnum.MAXSHAREDSIZE, 

Ains  t  rue t ure ->shmi  d , freespace) ; 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
ins t rue t ure->sendsem  =  semt  ran( sendpor tnum)  ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
ins t rue ture->recei vesem  =  semt  ran( receivepor tnum)  ; 
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/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini  t_shared_buf f er( ins  t  rue  t ure->segment ) ; 

/*  spawn  off  the  sender  process  */ 

if(  strcmp(  server,  "receive"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  +/ 
s  t  rcpy  ( t  emp ,  SEMXXXATION) ; 
s  t  rcat ( temp, "  " ) ; 

/*  add  the  number  of  the  sharedsegment  in  text  */ 
sprintf( t  emp 2 ,  "%d" , ins  t  rue ture->shmid) ; 
s  t  re  a  t ( t  emp , t  emp2 ) ; 
8  t  rcat ( temp, "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp.mname) ; 

s  t  r  c  a  t ( t emp , "  " ) ; 

/*  add  the  port  number  */ 

spr  in t  f ( t  emp 2 ,  "%d" , sendpor  tnum)  ; 

s  t  re  a  t  ( t  emp ,  t  emp2 ) ; 

s  t  rcat ( temp, "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  rca t ( t  emp, server ) ; 
s  t  r  c  a  t ( t  emp , "  0&"  ) ; 

/*  spawn  off  the  sender  into  the  background  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  - 1  ) 

per ror ( "SFJC)  system  call  failed"); 


else 

I 


/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thing  does  not  have  to  be  done  for  recei ver_has_da t a( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 

k i 1 lsende r (  i ns t r uc t u r e ->segmen t ,  ins t rue ture->sendsem  ); 


/*  spawn  off  the  receiver  process  */ 
if(  strcmp(  server,  "broadcast"  )  1=  0  ) 


I 


/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
st  rcpy(  temp.RECEIVELOCATION) ; 
strcat(t emp , "  " ) ; 

I*    add  the  number  of  the  sharedsegment  in  text  */ 
spr  int  f ( t emp 2 , "%d" , ins  t  rue  ture ->snmi  d) ; 
s  t  rcat ( temp, t emp2) ; 
s  t  rca t ( t  emp, "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rcat  ( t  emp.mname) ; 
s  t  rcat ( temp, "  " ) ; 

/*  add  the  port  number  */ 
sprintf( t  emp  2 , "%d" .receivepor  tnum)  ; 
s  t  rca  t ( temp, t emp2) ; 
s  t  rca t ( temp, "  " ) ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  rca t ( temp, server) ; 
st rcat (temp,"  0&"  ) ; 
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/*  spawn  off  the  receiver  into  the  background  */ 
if(  s  y  s  t  em(  t  emp )  ==  - 1  ) 

perror( "RECEIVE  system  call  failed"); 

I 
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/• 

For  direct  connection,  both  send  and  receive  processes  are  spawned. 
For  broadcast,  either  send  or  receive  process  is  spawned. 
The  dynami cmachinepa ths  routine  performs  the  following: 

(1)  creates  a  shared  segment  large  enough  for  multiple  attachments 

and  attaches  it  to  the  main  program  virtual  space  after  an  allocation 
of  free  memory  space. 

(2)  creates  a  send  and/or  receive  semaphore  based  on  the  send  and  receive 
port  numbers. 

(3)  free_8ender( segment )  and/or  f ree_receiver ( segment ) 

(4)  spawns  off  the  send  and/or  receive  processes. 

system("send  sharedseg#  machinename  port#  server /c I ient /broadcas t  ()&"); 
sys t em(  " rece i ve  sharedseg#  machinename  port#  server /c 1 ient / receive  0&" ) ; 

(5)  the  send  and  receive  semaphores,  the  pointer  to  the  shared  segment, 
and  the  id  of  the  shared  segment  are  placed  in  a  structure  of  type 
Machine  that  is  declared  in  the  calling  program. 

*/ 

dynami  cmachinepa ths (nuirmac nines , segment num.mname  , sendpor  tnum,  recei vepor  tnum, 

server, instructure, free  space) 

int  nunmac nines ;   /*  the  maximum  number  of  other  machines  to  be  attached  */ 

long  segmentnum;   /*  the  key  to  use  for  the  created  shared  segment  */ 

char  mnamc[);      /*  machinename  character  string  */ 

long  sendpor tnum,  recei vepor tnum;    /*  send  and  receive  port  numbers  */ 

char  server!];     /*  this  character  string  is  either  "client",  "server", 

"broadcast",  or  "receive".   If  direct  connection  wanted, 
it  indicates  whether  the  sender /recei ver  should  open 
up  as  either  a  client  or  server.  The  first  guy  open 
must  be  the  server.   If  broadcast  wanted,  it  indicates 
whether  to  open  up  as  broadcaster  or  receiver. 
•/ 

Machine  * i ns t rue t urc  ;    /*  structure  to  hold  segment  and  semaphore  info: 

char  *  ins t rue ture . segment  --  returned  ptr  to  the  shared  segment. 

int  ins t rue i ure . shmid  --  returned  system  generated  shared  mem  id 

int  ins t rue t ure . sends  em  --  the  returned  send  semaphore. 

We  base  i t  on  the  send  portnumber. 

int  ins t rue ture . recei vesem  --  the  returned  receive  semaphore. 

We  base  it  on  the  receive  portnumber. 
•/ 

int  freespace;     /*  amount  of  freespace  desired  for  dynamic  memory  allocation 

after  this  routine  has  been  called.  */ 

I 

char  *dynami  c sharedsegmen t (  ) ;     /*  shared  segment  creation  function  */ 

int  semtran();  /*  semaphore  creating  routine.  */ 

char  temp[200],  temp2[200];  /*  temp  character  arrays  */ 

static  Boolean  firsttime  =  TRUE;  /*  flag  to  detect  multiple  requests  */ 

static  int  sequencenum   =  0;  /*  sequence  number  for  receive/send  */ 

static  int  totmachines;  /*  max  attachments  permitted  */ 

/*  check  for  first  time  called  and  establish  max  possible  attachments  */ 
if(  firstt  ime  ) 
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totmachines  =  nunmachines ; 
first  time   =  FALSE; 

) 
else 

++sequencenum; 

/*  check  for  violation  of  maximum  attachments  */ 
if(  sequencenum  >=  totmachines  ) 

( 

perror ( "mpath :  Too  many  attachments  attempted"); 

exit(  -1  ); 
} 

/*  create  the  shared  segment  */ 

ins t rue ture->segment  =  dynamic sharedsegmen t ( nunmach i ne s , segment num, 

MAXSHAREDSIZE, 
&i  ns  t rue ture->shmid, freespace) 

/*  create  the  send  semaphore,  (unused  if  receiving  broadcast  messages)  */ 
ins t rue t ure->sendsem  =  semt  ran( sendpor tnum)  ; 

/*  create  the  receive  semaphore  (unused  if  broadcasting  messages)  */ 
ins t rue ture->receivesem  =  semt  ran( receivepor tnum)  ; 

/*  free  the  sender  and  receiver  parts  of  the  shared  segment  */ 
ini  t_shared_buf f er( ins t  rue ture->segment ) ; 

/*  spawn  off  the  sender  process  */ 

if(  strcmp(  server,  "receive"  )  !=  0  ) 

I 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
strcpy(  temp.SEMMXCATION)  ; 
s t  rcat ( temp, "  " ) ; 

/*  add  the  number  of  the  sharedsegment  in  text  */ 
spr int  f ( I emp2 , "%d" , ins t rue ture->shmid) ; 
strcat(t  emp , t  emp2 ) ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  (  t  emp.mname) ; 
s  t  rcat ( temp, "  " ) ; 

/*  add  the  port  number  */ 

spr  int  f ( t  emp 2 , "%d" , sendpor  tnum)  ; 

strcat(t  emp , t  emp  2 ) ; 

st rca t ( temp, "  "); 

/*  indicate  whether  a  server,  a  client,  or  a  broadcaster  */ 
s  t  r  c  a  t ( t  emp  .server); 
st rcat (temp,"  "); 

/*  add  the  machine  sequence  number  */ 
sprintf( t emp 2 , "%d" , sequencenum)  ; 
strcat(t  emp , t  emp  2 ) ; 

/*  spawn  off  into  the  background  */ 
s  t  rca t ( temp, "&"  ) ; 

/*  spawn  off  the  sender  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  - 1  ) 

perror("SET€>  system  call  failed"); 

) 

e  1  se 

I 

/*  kill  sender  (which  really  doesn't  exist  anyway)  so  that  the 
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sender_i s_f ree( )  call  will  always  return  FALSE. 

A  similar  thins  does  not  have  to  be  done  for  recei ver_has_dat a( ) 
in  a  broadcasting  path  since  it  will  always  return  FALSE  anyway  */ 
kill_sender(  ins t rue t ure->segment ,  ins t rue ture->sendsem  ); 

I 

/*  spawn  off  the  receiver  process  */ 

if(  strcmp(  server,  "broadcast"  )  !=  0  ) 

{ 

/*  add  the  start  of  the  line,  i.e.  the  program  to  run  */ 
strcpy(  temp.RECEIVELOCATIGN); 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  number  of  the  sharedsegmen t  in  text  */ 
sprint  f( t  emp 2 , "%d" , ins  t  rue  ture->shmid) ; 
s  t  r  c  a  t  ( t  emp ,  t  emp  2  )  ; 
s  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  on  the  machine  name  */ 
s  t  rca  t  ( t  emp, m name  )  ; 
s  t  rcat ( temp, "  " )  ; 

/*  add  the  port  number  */ 

sprint  f ( temp2 , "%d" .receivepor  tnum) ; 

s  t  r  c  a  t  ( t  emp ,  t  emp  2 )  ; 

s  t  r  c  a  t ( t  emp ,  "  "  )  ; 

/*  indicate  whether  a  server,  a  client,  or  a  broadcast  receiver  */ 
s  t  rca t ( t  emp, server ) ; 
8  t  r  c  a  t ( t  emp , "  " ) ; 

/*  add  the  machine  sequence  number  */ 
spr  in t  f ( t  emp 2 ,  "%d" , sequencenum) ; 
s  t  r  c  a  t ( t  emp , t  emp  2 ) ; 

/*  spawn  off  into  the  background  */ 
st rcat ( temp,"&") ; 

/*  spawn  off  the  receiver  */ 
i  f (  s  y  s  t  em(  t  emp )  ==  - 1  ) 

perror( "RECEIVE  system  call  failed"); 
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a.  Calling  Protocols 

This  module  contains  the  low-level  socket-managing  calls.  No  functions  in 
this  module  are  intended  for  application  programs.  This  module  is  only  linked  into  the 
send  and  receive  processes. 

b.  Code  and  Description 


TITLE 
MODULE 
VERSION 
DATE 


Inter -Computer  Communication  Package 

netV.c 

5.0 

31  May  1988 


AUTHOR  :  Theodore  H.  Barrow 

HISTORY: 

VERSION:  1.0 

DATE    :  19  November  1986 

AUTHOR  :  Michael  J.  Zyda 

DESC.   :  Contains  routines  connec t_server  and  connec t_c 1 ien t  to  allow 
two  machines  with  Unix  System  V  to  conmunicate  via  sockets. 

VERSION:  2.0 

DATE    :  29  April  1987 

AUTHOR  :  Michael  J.  Zyda 

DESC.   :  Converted  to  work  with  4 . 2BSD  sockets. 

VERSION:  3.0 

DATE    :  27  May  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Eliminated  excess  variables,  some  unused  and  some  unnecessary. 

VERSION:  4.0 

DATE    :  21  August  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.  Improved  reliability  of  socket  connection  and  disconnection. 

VERSION:  5.0 

DATE    :  31  May  1988 


94 


netV.c 

AUIHOR  :  Theodore  H.  Barrow  * 

* 

DESC.  :  Added  s t ar t_broadcas t ( )  and  broadcas t_recei ve( )  to  provide  * 
datagram  sockets  for  broadcast  use.  These  sockets  use  the  * 
default  Internet  broadcast  addressing.  * 

^^4,*^************** ************************************************  ********** 

* 

RECORD  OF  CHANGES  * 

* 

Version*   Date   *   Author  *  *   Affected    *Reqd* 

*  Change  Description  *   Modules    *Vers* 

4.1   *  4Jan88  *  T.  H.  Barrow        *  *  send.c       *4.0  * 

*  Changed  include  library  pathnames  for  IRIS  4D.*  receive. c    *4.0  * 

m,^n,^^^^t********** ************************************************  ********** 

*  *  *  *  *  * 

*  *  *  * 
*^t************************************************************************* / 
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/* 

This  segment,  when  linked  into  a  program  on  a  computer  with  a  UNIX  4.2  BSD 

operating  system,  will  allow  the  program  to  corrmunicate  with  programs 

executing  on  other  computer  systems  over  an  Internet  network. 
*/ 

#define  TRUE  1 

/*  include  files  for  UNIX  4.2  BSD.   These  are  all  called  from  the  bsd 

subdirectory  in  /usr / inc lude .   The  file  sys/types.h  also  exists  and  is 
included  when  bsd/sys/ types . h  is  used.   This  was  done  for  ease  of  change 
if  and  when  Silicon  Graphics  changes  the  include  library  structure.  */ 

#include  <sys/ types . h> 

#include  <sys/socke t . h> 

#include  <bsd/ne t ine t / in . h> 

#include  <bsd/ne t db. h> 


/ 


it********************************************************** 


The  connec t_server ( remot e_c I ien t_name ,  por t_number )  function  performs 

the  actions  required  to  connect  a  server  system  to  a  remote  client  system 


*+++***+**+*++*******+**+*++****++*+**+++++*+**+*+++**+*#*++ 


/ 


int  connec t_server( remote_cl ient_name  ,  port_number) 

char  remote_cl ient_name[ ] ;   /*  name  of  the  remote  client  system  */ 

int   port_number;  /*  port  number  to  the  remote  client  system  */ 


I 


char  *pt r_c 1 ien t_name ;      /*  pointer  to  the  remote  client  system's  name  */ 

int  local_server_socke t ;    /*  local  socket  number  */ 

int  socket) );  /*  function  that  opens  a  socket  */ 

int  acceptQ;  /*  function  that  accepts  a  connection  from 

a  remote  client  socket  */ 

int  remot e_c 1 i ent_socket  =  -1;   /*  socket  number  of  remote  client  system  */ 

/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address   =  {  AF_INET  J; 

long  remot e_c 1 ien t_address ;      /*  address  of  the  remote  client  system  */ 

short  remot e_c 1 ient_por t ;        /*  port  number  of  the  remote  client  system  */ 

int  addres s_s ize ;  /*  size  of  address  of  remote  client  system  */ 

/*  create  socket  structure  from  input  parameters  */ 

/*  get  a  pointer  to  the  remote  client  system's  name  */ 
pt r_c 1 ient_name  =  remot e_c 1 ien t_name  ; 

/*  convert  the  remote  client  system  name  to  its  address. 

Note  that  ge thos t byname ( )  requires  a  pointer  to  a  pointer  */ 
remote_c 1 ien t_address  =  ( long)ge thos tbyname(&pt r_c 1 ien t_name) ; 

/♦  set  the  remote  client  port  number  above  the  system  reserved  ports 

by  adding  the  remote  client  port  number  to  the  number  of  reserved  ports  */ 
remote_client_port  =  I PPORT_RESERVED  +  port_number; 

/*  remote  client  system  address  family  (Internet  in  this  case)  */ 
address . s i n_f ami ly  =  AF_INET  ; 
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/*  place  the  remote  client  port  number  into  the  address  data  structure 

in  network  byte  order  */ 
address . sin_port  =  ht ons( remote_c 1 ient_por t ) ; 

/*  place  the  remote  client  system's  address  in  the  address  data  structure  */ 
address . s in_addr . s_addr  =  remote_c 1 ient_address ; 

/*  find  number  of  bytes  in  the  remote  client  address  */ 
address_size  =  s izeof ( remot e_c 1 ien t_address ) ; 

/*  attempt  to  open  a  local  socket  */ 
local_server_socket  =  socket  (AF_INET,SOCK_STREAM,  0) ; 

i f ( local_server_socke t  <  0) 

per ror ( "Server  couldn't  open  a  local  socket:"); 
else 

I 

i f (bind( 1 ocal_server_socke t ,  (caddr_t )&addres s ,  s izeof ( addres s ) )  <  0) 
per ror( "Server  couldn't  bind  address  to  local  socket:"); 

/*  set  the  maximum  number  of  remote  client  systems  to  be  connected  to  */ 
listen(local_server_socket  ,  SCM^XOONN)  ; 

pr in t f( "Server  waiting  to  connect  to  %s\n" , remote_cl ien t_name ) ; 

/*  attempt  to  accept  a  connection  */ 

remot e_c 1 i en t_socket  =  accept ( local_server_socke t ,  &address, 

&address_8  i  ze ) ; 

i f( remot e_c 1 ien t_socke t  <  0) 

I 

/*  an  error  occurred  in  the  server  attempting  to 

accept  a  connection  from  remote  client  system  */ 
per ror (  'Server  couldn't  accept  connection  from  remote  client  system:") 

shut  down  ( local_server_socket,  2); 
close(local_server_socket); 

) 

/*  else  the  server  accepted  a  connection  from  the  remote  client  system  */ 


/*  return  the  socket  number  of  the  remote  client  system  */ 
re  t  urn( remot e_c lient_socket); 

)  /*  connec t_server  */ 
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/ft********************************************************* 

The  connec t_cl ien t ( remot e_server_name ,  port_number)  function  performs 
all  the  actions  required  to  connect  a  client  system  to  a  remote  server 
s  y  s  t  em 


it********************************************************* 


/ 


i  11 1  connec  t_c  1  ient  (  remot  e_server_name  ,  port_number) 

char  remote_server_name [ ] ;    /*  name  of  the  remote  server  system  */ 

int   port_number;  /*  port  number  to  the  remote  server  system  */ 


( 


int  local_c 1 ient_socke t ;        /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

/*  function  that  connects  local  socket  to  remote  server  socket  */ 
int  connec  t ( ) ; 

int  remot e_server_socket ;       /*  socket  number  on  remote  server  system   */ 

/*  the  protocol  and  address  data  structure  specified  for  the  socket  */ 
static  struct  sockaddr_in  address  =  (  AF_INET  }; 

struct  hostent  *remot e_server_address ;  /*  address  of  remote  server  system  */ 

short  remote_server_port ;  /*  port  number  of  remote  system  */ 

/*  create  socket  structure  from  input  parameters  */ 

/*  convert  the  remote  server  system  name  to  its  address. 

Note  that  ge thos tbyname( )  requires  a  pointer  only  in  this  case  */ 
remote_server_address  =  ge thos t byname ( remote_server_name  ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *)&address,  s izeof( address )) ; 

/*  copy  the  remote  server  address  structure  into  the  address  structure  */ 
bcopy ( remot  e_server_address ->h_addr , 

(char  * )&addres s . s in_addr , 

remot e_server_addres s ->h_ length) ; 

/*  set  remote  server  port  number  above  the  system  reserved  ports  by  adding 
the  user's  remote  server  port  number  to  the  number  of  reserved  ports  */ 
remote_server_port  =  I PPORT_RESERVED  +  port_number; 

/*   remote  server  system  address  f ami  ly( In ternet  in  this  case)  */ 
addre ss . s in_f ami ly  =  AF_INET; 

/*  place  the  remote  server  port  number  into  the  address  structure 

in  network  byte  order  */ 
address . s in_port  =  h t ons ( remote_server_por t ) ; 

/*  attempt  to  obtain  a  local  socket  */ 
local_client_socket  =  socke  t  (AF_INET,  SOCK_STREAM,  0); 

i f ( local_c 1 ient_socke t  <  0) 

perror ( "CI ien t  couldn't  open  a  local  socket:"); 
else 

I 

/*  place  Internet  address  family  type  in  address  structure  */ 
addres s . s in_f ami ly  =  AF_INET; 
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/*  attempt  to  connect  local  client  socket  to  remote  server  socket  */ 
remote_server_socke t  =  connec t ( local_cl ien t_socke t ,  (caddr_t )&addre s s , 

s  izeof (addres  s ) ) ; 

i f ( remote_server_socke t  <  0) 

I 

/*  error  occurred  in  attempting  to  connect  to  remote  server  socket  */ 
per ror ( "CI ient  couldn't  connect  to  the  remote  server  socket:"); 

shut  down  ( local_cl ient _ socket ,  2) ; 
close(local_client_socket); 

/*  set  local_cl ient  socket  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local_c 1 ien t_socke t  =  remot e_server_socke t ; 

) 

else 

/*  successfully  connected  to  the  remote  server  system  */ 

pr in t f( "Connec t ion  established  with  %s . \n" , remote_server_name) ; 


/*  return  the  socket  number  of  the  local  client  system  */ 
return(local_client_socket); 

)  /*  connec t_c 1 ient  */ 
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The  s t art_broadcas t (por t_number )  function  performs 

the  actions  required  to  initiate  a  datagram  broadcast  socket. 

int  s t ar t_broadcas t (por t_number) 

int   port_number;  /*  port  number  for  the  remote  receiver  system  */ 

( 

int  broadcas t_socke t ;    /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  */ 

int  se t sockopt ( ) ;        /*  function  that  sets  a  socket  to  allow  broadcast  */ 

int  on  =  TRUE;  /*  to  set  broadcast  toggle  on  for  socket  */ 

/*  protocol  and  address  data  structure  for  socket  */ 
static  struct  sockaddr_in  address   =  (  AF_INET  ); 

short  broadcas t_por t ;        /*  port  number  broadcast  heard  from  */ 

/*  create  local  socket  structure  from  input  parameters  */ 

/*  set  the  broadcast  port  number  above  the  system  reserved  ports 

by  adding  the  broadcast  port  number  to  the  number  of  reserved  ports  */ 
broadcas t_port  =  IPPORT_RESERVED  +  port_number; 

/*  system  address  family  (Internet  in  this  case)  */ 
address . s in_f ami ly  =  AF_INET  ; 

/*  place  the  port  number  into  the  address  data  structure 

in  network  byte  order  */ 
address . s in_por t  =  htons (broadcas t_por t ) ; 

/*  place  the  local  address  in  the  address  data  structure 

in  network  byte  order  */ 
address . s in_addr . s_addr  =  h t on  1 ( INADDR_ANY) ; 

/*  attempt  to  open  a  local  socket  */ 
broadcast_socket  =  socke t (AF_INET,SOCK_DGRAM,  0) ; 

i f (broadcas t_socke t  <  0) 

perror( "Broadcaster  couldn't  open  a  local  socket:"); 
else 

I 

/*  set  the  broadcas t_socket  for  broadcasting  */ 
if (set sockopt (  broadcas t_socket ,  SOL_SOCKET,  SOJBRQADCAST , 
&on ,  sizeof(on)  )  <  0) 
per ror ( "Broadcas ter  couldn't  set  socket  to  broadcast:"); 

else  if(bind(  broadcas t_socke t ,  (struct  sockaddr  *)&address, 

s izeof( address )  )  <  0) 

per ror ( "Broadcas ter  couldn't  bind  to  local  socket:"); 
e  1  se 

I 

pr int f (  "Wai t ing  to  broadcas t\n" ) ; 

I 
) 

/*  return  the  socket  number  */ 
return(broadcast_socket  )  ; 

}  /*  s t ar t_broadcas t  */ 
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/ft********************************************************** 

The  broadcas t_rece ive(broadcas ter.name .por t_number )  function  performs 
all  the  actions  required  to  set  up  a  broadcast  receiving  socket 


it********************************************************* 


in t  broadcas  t_receive(broadcas  ter_name , por t_number ) 

char  broadcas ter_name  [] ;    /*  name  of  the  broadcaster  system  */ 

int   port_number;  /*  port  number  for  the  broadcaster  */ 

( 

int  local_socket ;        /*  local  socket  number  */ 

int  socket();  /*  function  that  opens  a  socket  ♦/ 

int  broadcas t er_socket ;  /*  socket  number  on  broadcaster  system   */ 

/*  the  protocol  and  address  data  structure  specified  for  the  socket  *  / 
static  struct  sockaddr_in  address  =  {  AF_ INkV  ); 

struct  hostent  *broadcas t er_address ;  /*  address  of  broadcaster  system  */ 

short  broadcas ter_port ;  /*  port  number  of  remote  system  */ 

/*  create  socket  structure  from  input  parameters  * / 

/*  convert  the  broadcaster  system  name  to  its  address. 

Note  that  ge thos t byname ( )  requires  a  pointer  only  in  this  case  */ 
broadcas t er_address  =  ge t hos (byname  (broadcas t e r_name ) ; 

/*  clear  out  the  address  structure  */ 
bzero((char  *  )&addres s ,  s izeof ( addres s ) ) ; 

/*  copy  the  broadcaster  address  structure  into  the  address  structure  */ 
bcopy(broadcaster_address ->h_addr , 

(char  *)&address . sin_addr , 

broadcas  ter_address ->h_ length) ; 

/*  set  broadcaster  port  number  above  the  system  reserved  ports  by  adding 
the  user's  broadcaster  port  number  to  the  number  of  reserved  ports  */ 
broadcaster_port  =  I PPORT_RESERVED  +  port_number; 

/*   broadcaster  system  address  f ami  ly( Internet  in  this  case)  */ 
address . s in_f  ami ly  =  AF_1NET; 

/*  place  the  broadcaster  port  number  into  the  address  structure 

in  network  byte  order  */ 
address . s in_port  =  htons (broadcas ter_por t ) ; 

/*  attempt  to  obtain  a  local  socket  */ 
local_socket  =  socke  t  (AF_INET,  SOCKJXJRAM,  0); 

i f ( local_socke t  <  0) 

( 

perrorl "Receiver  couldn't  open  a  local  socket:"); 

else 

( 

/*  attempt  to  connect  local  socket  to  broadcaster  socket  */ 
broadcas t er_socket  =  connec t ( local_socke t ,  (struct  sockaddr  *)&address, 

sizeof(address)) ; 
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i f (broadcas ter_socket  <  0) 

I 

/*  error  occurred  in  attempting  to  insert  broadcaster  information  */ 
per ror ( "Rece i ver  couldn't  find  broadcaster:"); 

shutdown( Iocal_socket ,  2); 
c 1 ose ( local_socke  t ) ; 

/*  set  Iocal_socket  so  that  negative  value  is 
always  returned  when  an  error  occurs 

*/ 

local_socket  =  broadcas ter_socket ; 

I 

else 

/*  successfully  listening  to  the  broadcaster  system  */ 
pr int f( " ready  to  receive  from  %s  . \n" , broadcas ter_name) ; 

I 

/*  return  the  socket  number  of  the  local  system  */ 
re  t urn( local_socke  t ) ; 

/*  broadcas t_receive  */ 
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a.  Calling  Protocols 

This  program  monitors  a  socket,  like  a  daemon.  It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line. 

b.  Code  and  Description 

i^^^^t******* *************************************************  *************** 

*      TITLE 


*  MJDULE 

*  VERSION 


Inter-Computer    Corrmun  icat  ion    Package 

receive . c 

3.0 

31  May  1988 

Theodore  H.  Barrow 


*  DATE 

*  AUTHOR 

* 

**00000t****** *************************************************************** 

* 

*  HISTORY: 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

* 

**** 

* 

* 

♦Version*   Date   *   Author  *  *   Affected    *Reqd 

*  *      Change  Description  *   Modules    *Vers 

*  *  *  *  *  * 

*  *  *  * 
t**************************************************************************** I 


VERSION 

DATE 

AUTHOR 

DESC. 

VERSION 

DATE 

AUTHOR 

DESC. 


1.0 

6  February  1987 

Mi  chael  J .  Zyda 

Background  process  to  receive  messages  over  link. 

2.0 

15  December  1987 

Theodore  H.  Barrow 

Added  capability  to  get  sequence  number  from  command  line 
and  use  it  to  get  offset  into  shared  memory  segment. 


VERSION 

DATE 

AUTHOR 


3.0 

31  May  1988 

Theodore  H.  Barrow 

DESC.   :  Added  broadcast  receive  capability 

000^^******************************* ************************************* 

RECORD  OF  CHANGES 
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# include  "shared. h" 
# i nc I ude  "gl . h" 

main( argc , argv) 

int  argc;    /*  argument  count  */ 

char  *argv[];    /♦  pointers  to  the  passed  in  arguments  */ 

I 

/*  we  need  to  declare  character  variables  for  everything  passed  in  */ 

char  shmids  t  r  [  10]  ;    /*  shared  segment  string  holding  the  integer  key4*/ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  *segment;         /*  character  pointer  to  the  shared  segment  */ 

int  receivesem;        /*  receive  semaphore  */ 

char  *sharedsegmen t ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];       /*  machine  name  */ 

char  portstr[10];      /*  port  number  string  */ 

long  portnum;  /*  port  number  pulled  from  the  string  */ 

char  server[10];        /*  server  string  */ 

char  seqnos t r [ 10] ;     /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t_server( ) ; 

int  connec t_c 1 ient () ; 

int  broadcas t_recei ve( ) ; 

int  recei ver_i s_f ree( ) ; 

int  recei ver_shou ld_die( ) ; 

int  semtran();        /*  semaphore  creation  routine.  */ 

/*  pull  out  the  strings  from  the  argument  list  */ 
i  f ( argc  <  5) 

I 

print f( "RECEIVE:  incorrect  argument  count !\n"); 

exit(l); 
I 

/*  pull  out  the  shared  memory  string  */ 

s t  rcpy( shmids  tr,argv[l]); 

s  scanf  (  shmids  t  r  ,  "%d"  ,&shmid)  ; 

/*  pull  out  the  machinename  string  */ 

s  t  rcpy (mname , a  rgv [2 ]  )  ; 

/*  pull  out  the  port  number  string  */ 
strcpy(portstr,argv[3]); 
3scanf(portstr, "%d" ,&por  t num)  ; 
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/*  create  the  receive  semaphore  */ 
receivesem  =  semt  ran(por tnum)  ; 

/*  pull  out  the  c  1  ient /server  string  */ 
strcpy (server, argv [4]); 

/*  pull  out  the  sequence  number  string  */ 
if(  argc  >  4  ) 

I 

strcpy(seqnostr,argv[5]); 

s  scanf ( seqnos  t  r ,  "%d" ,&s  equencenum) ; 

} 

/*  attach  to  the  shared  memory  segment  */ 

i f( (  in t  )( segment  =  (char  * ) shmat ( shmid,  0,  0666))  <  0) 

I 

perror( "RECEIVE: shmat"); 
exi t(0); 

} 

/*  create  the  shared  segment  address  to  use  */ 
segment  +=  sequencenum  *  MAXSHAREDSIZE; 

/*  open  the  socket  connection  to  the  named  machine  */ 
i f( s t rcmp( server ," server" )  ==  0) 

I 

/*  we  should  open  as  the  server  */ 
socket  =  connec t_server  (mname ,por tnum) ; 

) 

else  i f( st rcmp( server , "receive" )  ==  0) 

I 

/*  we  should  open  as  the  broadcast  receiver*/ 
socket  =  broadcas t_rece i ve  (mname ,por tnum) ; 

I 
else 

( 

/*  we  should  open  as  a  client  */ 

socket  =  connec t_c 1 ient  (mname ,por tnum) ; 
I 

/*  check  to  make  sure  socket  was  opened,  exit  if  not  */ 
if(socket  <  0) 

I 

print f( "RECEIVE:  socket  connection  NOT  madel\n"); 
exit(l); 

} 

/*  the  infinite  loop...  */ 

i f( s t rcmp( server , "receive" )  ==  0) 
while (TRUE) 

I 

/*  should  the  receiver  die??7  */ 

i  f ( receiver _should_die( segment , receivesem) ) 

I 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  +/ 

de  t  ach shared segment ( segment ) ; 

shu t down( socke t ,  0); 

c lose( socke  t ) ; 

exit(0); 
) 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if(receiver_is_free( segment ) ) 

I 

/*  check  socket  and  read  into  segment  if  proper  message  */ 
i f (broadcas t_into_segmen t ( socke t , segment , mname  ,por tnum)  >  0) 
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) 


/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e 
the  data  has  been  read  out  */ 

P( receivesem)  ; 


}    /*  end  while  true  for  broadcasting*/ 
else 

while(TRUE) 

I 

/*  should  the  receiver  die???  */ 

i  f ( rece  i  ver_should_die( segment , receivesem) ) 

I 

/*  exit  after  detaching  shared  segment  and  cleaning  up  socket  */ 

de  t  ach shared segment ( segment ) ; 

shut down( socket ,  0); 

close( socket ) ; 

exit(0); 
} 

/*  if  the  receiver  part  of  the  segment  is  free,  read  onto  it  */ 
if(receiver_is_free( segment ) ) 

i 

I*    read  socket  into  segment  */ 

read_socke  t_into_ segment ( so eke  t , segment ) ; 
} 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the 
graphics  program  that  the  receiver  segment  is  free,  i.e. 
the  data  has  been  read  out  */ 

P( rece  i vesem)  ; 

}    /*  end  while  true  for  direct  connections*/ 
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5.     semaphores 

a.  Calling  Protocols 

This  module  repackages  the  low-level  semaphore  calls  into  a   P  and  a   V 
semaphore  operation.  No  functions  in  this  module  are  intended  for  application  programs. 

b.  Code  and  Description 

f*m************************************************************************** 

TITLE  In ter -Computer  Conmunicat ion  Package 

MDULE  :  send.c 

VERSION:  1.0 

DATE    :  11  February  1987 

AUTHOR  :  Michael  J.  Zyda 

I*************************************************************************** 

HISTORY: 


VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

11  February  1987 

Michael  J.  Zyda 

Implements  P  and  V  semaphore  operations  for  Unix  system  V. 
Based  on  an  example  from  Advanced  Unix  Procranmini 


Based  on  an  example  trom  Advanced  Unix  f rograirmi ng . 

**************************************************************************** 

RECORD  OF  CHANGES 

Version*   Date   *   Author  *  *   Affected    *Reqd 

*  Change  Description  *   Modules    *Vers 

***+*+*+**++*+** nit********************************************************* 

*  *  *  *  * 

*  *  * 

****************************************************************************! 
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#include  <sys/ types .h> 
^include  <sys/ipc.h> 
#include  <sys/sem.h> 

int  semtran(key)  /*  translate  semaphore  key  to  ID   */ 
in t  key ; 

I 

int  s  id; 

if  ((sid  =  semget((key_t)key. 1,06661  IPC.CREAT) )  ==  - 1 ) 

I 
perror("s  emge  t " ) ; 


) 


re  t urn( s  id) ; 


static  void  semcal 1 ( s id, op)  /*  call  semop   */ 
int  sid; 
int  op ; 


struct  sembuf  sb; 

sb  .  sem_num  =  0 
sb . sem_op  =  op 
sb . sem_f lg  =  0 

i f ( semop ( s id ,&sb, 1 )  ==  -1) 

{ 

per ror ( " semop" ) ; 

} 


void  P(sid)   /*  acquire  semaphore   */ 
int  sid; 

I 

s  emc  a  1 1 ( s  i  d  ,  -1); 

) 


void  V(sid)   /*  release  semaphore  */ 

int  sid; 

I 

s  emc  all(sid,  1); 
I 
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6.      send.c 

a.  Calling  Protocols 

This  program  monitors  a  socket,  like  a  daemon.  It  is  spawned  transparently  to 
the  user  and  receives  its  initialization  data  through  the  command  line. 

b.  Code  and  Description 


*  TITLE 

* 

*  MDULE 


Inter-Computer  Communication  Package 

send . c 

3.0 

31  May  1988 

Theodore  H.  Barrow 


*  VERSION 

*  DATE 

* 

*  AUTHOR 
***************************************************************************** 

*  HISTORY: 


VERSION:  1.0 

DATE    :  6  February  1987 

AUTHOR  :  Michael  J.  Zyda 

DESC.   :  Background  process  to  send  messages  over  link. 

VERSION:  2.0 

DATE    :  15  December  1987 

AUTHOR  :  Theodore  H.  Barrow 

DESC.   :  Added  capability  to  get  sequence  number  from  command  line 
and  use  it  to  get  offset  into  shared  memory  segment. 

VERSION:  3.0 

DATE    :  31  May  1988 

AUTHOR  :  Theodore  H.  Barrow 


DESC.   :  Added  broadcast  capability 

***<mi*m********************************************************************** 

* 

*  RECORD  OF  CHANGES 

* 

♦Version*   Date   *   Author  *  *   Affected    *Reqd 

*  *      Change  Description  *   Modules    *Vers 

*^tntnnt^tn,t******  ************************************************************ 

*  *  *  *  *  * 

*  *  *  * 

******4l^HL*^^4>****************************************************************f 
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#include  "shared. h' 
#inc lude  "gl .h" 


ma  in( argc , argv) 

int  argc;    /*  argument  count  */ 

char  *argv[J;    /*  pointers  to  the  passed  in  arguments  */ 

I 

/*  we  need  to  declare  character  variables  for  everything  passed  in  */ 

char  shmids t r [ 10] ;     /*  shared  segment  string  holding  the  integer  shmid  */ 

int  shmid;  /*  integer  pulled  out  of  the  string  */ 

char  ^segment;         /*  character  pointer  to  the  shared  segment  */ 

int  sendsem;  /*  send  semaphore  */ 

char  *sha redsegmen t ( ) ; /*  create  shared  segment  function  */ 

char  mname[100];       /*  machine  name  */ 

char  portstr[10];      /*  port  number  string  */ 

long  portnum;  /*  port  number  pulled  from  the  string  */ 

char  server[10];       /*  server  string  */ 

char  seqnos t r [ 10] ;     /*  sequence  #  string  holding  integer  sequence  #  */ 

long  sequencenum  =  0;  /*  integer  pulled  out  of  the  string  (default  0)  */ 

int  socket;  /*  the  opened  socket  descriptor  */ 

int  connec t_server ( ) ; 

int  connec t_c 1 ien t () ; 

int  s t ar t  broadcas t ( ) ; 

int  sender_has_da t a( ) ; 

int  sender_should_die( ) ; 

int  semtran();        /*  semaphore  creation  routine.  */ 

/*  pull  out  the  strings  from  the  argument  list  */ 
i  f ( argc  <  5) 

( 

pr  in  t  f  (  "SErO:  incorrect  argument  count !\n"); 

exi t(l) ; 
} 

/*  pull  out  the  shared  memory  string  */ 
s  t  rcpy ( shmids  tr,argv[l]); 
sscanf  (  shmids  t  r  ,  "%d"  ,&s timid) ; 

/*  pull  out  the  machinename  string  */ 
st  rcpy  (mname , argv [2] ) ; 

/*  pull  out  the  port  number  string  */ 
strcpy(porlstr,argv[3]); 
sscanf(portstr,  "%d"  ,&por t num) ; 

/*  create  the  send  semaphore  +/ 
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sendsem  =  semt  ran (por t num)  ; 

/*  pull  out  the  c 1 ient /server  string  */ 
strcpy (server, argv [4]); 

*   pull  out  the  sequence  number  string  */ 
f(  argc  >  4  ) 

strcpy(seqnostr,argv[S]) ; 

sscanf ( seqnos  t  r ,  "%d" ,&sequencenum) ; 


*  attach  to  the  shared  memory  segment  */ 

f ((int )(segment  =  (char  * ) shmat ( shmid,  0,  0666))  <  0) 

per  ror  (  "SErO:  shmat  "  ) ; 
exit(0); 


*  create  the  shared  segment  */ 
egment  +=  sequencenum  *  MAXSHAREDSIZE; 

*  open  the  socket  connection  to  the  named  machine  */ 
f( s t rcmp( server ," server" )  ==  0) 

/*  we  should  open  as  the  server  */ 
socket  =  connec t_server  (mname ,por tnum) ; 

Ise  if(  strcmp(  server,  "broadcast"  )  ==  0  ) 

/*  we  should  open  as  a  broadcaster  */ 
socket  =  s t ar t_broadcas t (  portnum  ); 


else 


/*  we  should  open  as  a  client  */ 
socket  =  connec t_c 1 i en t  (mname , por tnum) ; 


*    check  to  make  sure  socket  was  opened,  exit  if  not  */ 
f ( socket  <  0) 

pr in t f ( "SEhD:  socket  connection  NOT  made ! \n" ) ; 
exit(l); 


/*  the  infinite  loop...  */ 

if(  s  t  r  cmp (  server,  "broadcast"  )  ==  0  ) 
while(TRUE) 

( 

/*  should  the  sender  die???  */ 

i  f ( sender_should_die( segment , sendsem) ) 

{ 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 

de  t  achsh a  red segment ( segment )  ; 

shut down( socket ,  1); 

c 1 ose ( socket  )  ; 

exi t(0) ; 
I 

/*  if  there  is  data  in  the  shared  memory  segment,  ...  */ 
if(sender_has_data( segment ) ) 

I 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 
send_socke t_f rom_s egment (socket , por tnum,  segment ) ; 
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I 


/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 
program.  The  signal  will  indicate  that  the  graphics  program 
has  put  more  data  into  the  shared  segment. 

•/ 

P( sendsem)  ; 

)    /*  end  while  true  for  broadcasting4*/ 
else 

while(TRUE) 

I 

/*  should  the  sender  die???  */ 

i  f ( sender_should_die( segment , sendsem) ) 

I 

/*  exit  after  detaching  segment  and  cleaning  up  socket  */ 

de  t  ach  sha  redsegmen  t ( segment ) ; 

shut  down ( socket ,  1); 

c 1 ose ( socket ) ; 

exi t(0); 
) 

/*  if  there  is  data  in  the  shared  memory  segment,  ...  */ 
if( sender _has_data( segment ) ) 

I 

/*  write  the  data  in  the  shared  segment  onto  the  socket  */ 

wr i  te_socket_from_  segment (socket , segment ) ; 
) 

/*  at  this  point,  sleep  until  we  receive  a  signal  from  the  graphics 

Erogram.  The  signal  will  indicate  that  the  graphics  program 
as  put  more  data  into  the  shared  segment. 

*/ 

P(  sendsem)  ; 

}    /*  end  while  true  for  direct  connection*/ 
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7.     shared.h 

a.      Calling  Protocols 

This  module  has  all  the  predefined  constants  and  type  definitions.  It  must  be 
included  in  the  application. 
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b.      Code  and  Description 


*  TITLE 

* 

*  MXJULE 


Inter -Computer  Communication  Package 

shared. h 

4.0 

15  December  1987 

Theodore  H.  Barrow 


*  VERSION 

* 

*  DATE 

* 

*  AUTHOR 

*  HISTORY: 

* 
* 
* 
* 
* 
* 

* 
* 

* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 

* 
* 
* 

* 


VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

6  February  1987 

Michael  J.  Zyda 

Contains  all  defines  and  special  constants  for  shared 
memory  socket  system. 

2.0 

27  May  1987 

Theodore  H.  Barrow 

Added  a  typedef  of  structure  for  use  by  various  routines. 
Added  message  types  for  high  level  read/write  protocol. 

3.0 

21  October  1987 

Theodore  H.  Barrow 

Changed  dependencies  of  buffer  calculation  constants  so  that 
only  one  need  change.   Added  additional  message  types. 

4.0 

15  December  1987 

Theodore  H.  Barrow 

Added  field  to  buffer  set  so  that  each  link  would  have  its 
own  area  to  handle  partial  receipt  of  messages 


* 

+  RECORD  OF  CHANGES 

* 

♦Version*  Date   *  Author            *                   *   Affected    *Reqd 

*  *  Change  Description                           *    Modules    *Vers 

*  4.1   *  4Jan88  *  T.  H.  Barrow       *                   *             * 

*  *  Changed  pathname  to  include  /usr  for  IRIS1     *              *     * 

**  +  +  +  ***  +  ***♦*♦**  +  ♦***»♦**  +  ♦**  +  +  *.*  +  ♦  +  ***  (.****  +  ******  +  ***,**  +  ******»*******»***/' 
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r* 

the  following  3  defines  are  the  changeable  parameters 
LARGESTREAD  MJST  be  divisible  by  4 


*/ 
#d 


efine  SFJOLOCATION  " /usr/work/bar row/share3/send"  /*  the  name  of  the  program 

to  run  for  the  sender  */ 

#define  RECEIVELOCATION  "/usr/work/bar row/share3/recei ve"  /*  the  name  of  program 

to  run  for  the  receiver  */ 

#define  LARGESTREAD  252       /*  the  largest  read  (i.e.  buffer  size)  */ 

/*  The  following  defines  are  constants  or  arc  derived  from  LARGESTREAD  */ 

#define  SENDEROFFSET  (LARGESTREAD  +  4)    /*  the  sender  data  starts  here  */ 

#define  WSErOEROFFSET  ( SEM>EROFFSET  /  4)  /*  long  word  offset  for  sender  data  */ 

#define  RECEIVEROFFSET  0      /*  the  receiver  data  starts  at  byte  0  */ 

#define  WIECEIVEROFFSET  0      /*  the  receiver  data  starts  at  long  word  0  */ 

#define  PROTOO)LHOLDOFFSET  ( SEM5EROFFSET  *  2)    /*  holding  area  starts  after 

sender  &rc&   / 
#define  MAXSHAREDSIZE  ( PROTOOTLHOLDOFFSET  +  12)  /*  the  number  of  bytes  in  the 

shared  segment  */ 

#define  CHARACTER_TYPE  'B'  /*  code  for  characters  */ 

#define  INTEGERJTYPE  *I'  /*  code  for  integers  */ 

#define  FLOAT_TYPE  'R'  /*  code  for  floats  */ 

#define  CHARACTER_ARRAY  TYPE  *C*  /*  code  for  character  arrays  */ 

#define  INTEGER_ARRAY_TYPE  'J'  /*  code  for  integer  arrays  */ 

#define  FLOAT_ARRAY_TYPE  'S'  /*  code  for  float  arrays  */ 

#define  CHARACTER  SIZE   1  /*  character  size  in  bytes  */ 

#define  INTEGER_STZE     sizeof(l)    /*  integer  size  in  bytes  */ 
#define  FLOAT_SIZE       sizeof(l.O)  /*  float  size  in  bytes  */ 

/*  the  following  is  the  structure  type  definition  needed  for  each  machine 

you  want  to  communicate  to... 
*/ 

typedef  struct  { 

char  *  segment;    /+  ptr  to  shared  memory  segment  */ 

int  shmid;        /*  system  generated  shared  mem.  id  */ 

int  sendsem;      /*  semaphore  used  to  wakeup  the  sender 

proces  s . 
*/ 

int  receivesem;   /*  semaphore  used  to  wakeup  the 

rece  i ver  process ..  . 

•/ 

}  Machine  ; 
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TITLE 

MXXJLE 

VERSION 

DATE 

AUTHOR 


In ter -Computer  Communication  Package 

shareseg . c 

3.1 

24  February  1988 

Theodore  H.  Barrow 


8.   shareseg.c 

a.  Calling  Protocols 

This  module  contains  the  low-level  shared-memory  calls.  No  functions  in  this 
module  are  intended  for  application  programs. 

b.  Code  and  Description 

J**************************************************************************** 

* 
* 
* 
* 
* 
* 
* 
* 
* 
+ 
* 

***************************************************************************** 

*  HISTORY: 

+ 

* 

* 
* 
* 
* 

+ 
* 
* 
* 
+ 
* 
* 
* 
* 

* 
* 

* 
* 
* 
* 
* 


VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

6  February  1987 

Michael  J.  Zyda 

Contains  routines  to  manage  shared  memory  segment.   Creation 
attachment,  detachment  and  deletion  are  all  covered. 

2.0 

21  October  1987 

Theodore  H.  Barrow 

Added  function  dynamicsharedsegmen t  to  allow  dynamic  memory 
allocation  after  corrmun  i  ca  t  i  oris  link  established. 

3.0 

15  December  1987 

Theodore  H.  Barrow 


Modified  function  dynamicsharedsegmen t  for  use  with  multiple 
links.  First  call  does  shared  segment  creation.  Subsequent 
calls  return  address  for  the  next  buffer  set. 

********************************************************************  ********* 
* 

*  RECORD  OF  CHANGES 

* 

♦Version*   Date   *   Author  *  *   Affected    *Reqd 

Change  Description  *   Modules    *Vers 


*        *      Change  Description  * 

****************************<.***********************+******»***************** 


none 


*  3.1   *  24Feb88*  T.  H.  Barrow       * 

*  *  Added  compatibility  for  IRIS  4D.  *  *     * 

*****************************************************************************/ 
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#include  <sy s / sy smac ros . h> 
^include  <stdio.h> 
#include  <sys/ types . h> 
#include  <sys/ipc.h> 
#include  <sys/shm.h> 
#inc lude  <g 1 . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE   IRIS4D 

#el  se 

#define  MACHINE   IRIS3000 

#endi  f 

char  *  shared segment (key , nby tes , shmid) 

long  key;     /*  the  key  to  use  for  the  segment  */ 

long  nbytes;  /*  the  number  of  bytes  in  the  segment  */ 

int  *shmid;   /*  returned  shared  memory  id  name  */ 

I 

char  *buf;  /*  temp  char  pointer  */ 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

/*  allocate  a  shared  memory  segment  */ 

if(  (* shmid  =  shmget(  key,  nbytes,  0666  I  IPC_CREAT  ))  <  0  ) 

I 

per  ror  (  "  shrug  e  t  "  )  ; 
exi t(0); 

} 

/*  attach  to  the  shared  memory  segment  */ 
if((int)(buf  =  (char  * )  shmat (*shmid ,  0,  0666))  <  0) 

I 

perror("s  hma  t " ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RM1D,  Ajunkbuf  )  ==  - 1  ) 

per  ror  (  "  shine  t  1 "  )  ; 
exi t(0) ; 
I 

/*  return  the  pointer  to  the  shared  segment  */ 
re  t urn(buf ) ; 
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char  *a t t ach_wi thin_dat asegmen t (  key,  size,  shmid,  freespace  ) 

long  key;         /*  the  key  to  use  for  the  segment  */ 

long  size;        /*  the  number  of  bytes  in  the  segment  */ 

int  *shmid;       /*  returned  shared  memory  id  name  */ 

int  freespace;    /*  amount  freespace  desired  for  dynamic  allocation  */ 

( 

char  *enddata,  *buf;        /*  temporary  address  pointers  */ 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

char  *sbrk(),  *malloc(); 

/*  allocate  a  shared  memory  segment  */ 

if(  (*shmid  =  shmget(key,  size,  0666  I  IPC.CREAT) )  <  0  ) 

I 

perror ( " shmge t " ) ; 

exit(0); 
} 

/*  Ensure  at  least  as  much  unallocated  space  as  freespace  indicates. 
Normally  the  top  of  the  data  region  is  incremented  more  than  the 
minimum  required  to  meet  the  malloc()  request.   Using  malloc() 
and  free()  ensures  that  this  mechanism  is  available  for  subsequent 
dynamic  memory  allocations.   Direct  use  of  sbrk( )  system  call 
causes  the  malloc()  mechanism  to  fail  on  subsequent  allocation 
requests.   freespace  is  cast  to  unsigned  to  meet  malloc()  spec.  */ 

free(  malloc(  (uns igned) freespace  )); 

/*  find  the  top  of  data  region  */ 
enddata  =  sbrk(0); 

/*  round  up  to  the  next  page  boundary  for  attachment  of  shared 

memory  segment  */ 
buf  =  (char  *  )  ( (  i  n  t  )endda  t  a  -  ( ( in  t  )endda t  a  %  SHN-LBA)  +  SFM.BA)  ; 

/*  reset  top  of  data  region  to  be  above  shared  segment  */ 
if(  brk(  buf  +  size  )  <  0  ) 

I 

perror ( "brk" ) ; 

/*  Since  there  was  an  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_FMID,  Ajunkbuf  )  ==  - 1  ) 

per ror (  " shmc  1 1 "  ) ; 
exi t(-l); 
} 

/*  attach  to  the  shared  memory  segment  at  the  calculated  address  */ 
if(  ( int )shmat (*shmid,  buf,  0666)  <  0  ) 

I 

perror( "shmat " ) ; 

/*  Since  there  was  an  attachment  error,  delete  the  segment  */ 
if(  shmctl(  shmid,  IPC_RMID,  Ajunkbuf  )  ==  - 1  ) 

per ror (  " shmc 1 1 "  ) ; 
exi t(0) ; 

} 

re  t urn(  buf  ) ; 
)   /*  a t t ach_wi t hin_dat a  segment ( )  */ 
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char  "dynami  c  sha  redsegmen  t  (  nunmacli  i  ne  s  ,  key,  nbytes,  shmid,  freespace) 

int  nuraiiachines;  /*  maximum  number  of  machines  to  be  initiated  */ 

long  key;         /*  the  key  to  use  for  the  segment  */ 

long  nbytes;      /*  the  number  of  bytes  in  the  segment  */ 

int  ""shmid;       /*  returned  shared  memory  id  name  */ 

int  freespace;    /*  amount  freespace  desired  for  dynamic  allocation  */ 

I 

static  Boolean  firsttime  =  TRUE;  /*  allows  for  multiple  calls  */ 

static  char  * s  !  a r t shared ;  /*  start  of  shared  memory  space  */ 

static  int  *holdshmid;     /*  holds  shmid  for  subsequent  calls  */ 

i  f  (  f  ir  s  1 1  ime  ) 

I 

switch(  MACHINE  ) 

( 

case  IRIS4D: 

startshared  =  sha  redsegmen  t  (  key,  nurrmach  1  nes  *nby  t  e  s  ,  shmid  ); 

break; 
case  IRIS3000: 

startshared  =  (char  *)at t ach_wi  th in_dat a  segment (  key, 

nurrmach  ine  s*nby  t  e  s  ,  shmid,  freespace  ) 

break; 
def aul  t : 

perror(  "shareseg:  Unknown  machine"  ); 

}   /*  switch(  MACHINE  )  */ 

ho  Id shmid  =  shmid; 
firsttime  =  FALSE; 

) 

e  1  se 

I 

/*  start  next  buffer  immediately  above  last.  Return  the  same  shmid 
for  all  buffers.  Assumes  all  buffers  are  same  size  (true  if  all 
from  same  shared. h  definition.  */ 

startshared  +=  nbytes; 

*shmid  =  *ho  I  dshnii  d  ; 

) 

/*  return  pointer  to  the  proper  buffer  in  the  shared  segment  */ 

return(  startshared  ); 
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de  t  ach  sha  reds egmen  t ( segment ) 

char  *segment;    /♦  segment  to  detach  from  */ 

I 

int  returnvalue; 

if(  (int)segment  %  SHvLBA  1=  0  ) 

return(  1  ); 
else 

I 

if(  returnvalue  =  shmdt ( segment )  <  0  ) 

per ror ( " shmdt " ) ; 
return(  returnvalue  ); 


dele  t  e sha red segment ( segment , shmid) 

char  *segment;    /*  character  pointer  to  the  shared  segment  */ 

int  shmid;        /*  shared  memory  id...  */ 

I 

int  returnvalue; 

struct  shmid_ds  junkbuf;    /*  I  don't  care  what's  in  this  buffer  */ 

/*  detach  from  the  shared  segment  and  set  returnvalue  */ 
if(  returnvalue  =  de t achsharedsegment ( segment )  ==  0  ) 

/*  remove  the  shared  segment  from  the  system  and  reset  returnvalue  */ 
if(  returnvalue  =  shmc 1 1 ( shmid ,  IPC_RMID,  &junkbuf)  <  0  ) 
perror("shmct 1" ) ; 

re turn( returnvalue) ; 
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9.     support.c 

a.      Calling  Protocols 

This  module  contains  functions  that  are  intended  for  the  application's  use  and 

functions  that  are  used  exclusively  by  other  routines.   The  parameters  for  externally 

accessible  functions  are  described  below. 

i.      receiver _has_data 
int    receiver_has_data( instructure) 

Machine  *ins t rue ture  ;   /*  includes 

char  *ins t ructure . segment    a  pointer  to  the  shared  segment  */ 

ii.  sender js-free 

int  sender_is_f ree( ins t ructure) 

Machine  *ins t rue ture ;   /*  includes 

char  *  ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 
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b.      Code  and  Description 


i**** ************************************************************************* 

* 

*  TITLE 

*  MDULE 
4.0 


In  t  er  -Computer    Conrnun  ica  i  ion    Package 
suppor  t . c 


*  VERSION: 

* 

*  DATE 

*  AUTHOR 

****************************************************************************** 

* 

*  HISTORY: 

* 


31  May  1988 
Theodore  H.  Barrow 


VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 

VERSION 
DATE 
AUTHOR 
DESC. 


1.0 

6  February  1987 

Michael  J.  Zyda 

Contains  support  routines  for  shared  memory  conrnun ica t ions 
s  y  s  t  em . 

2.0 

27  May  1987 

Theodore  H.  Barrow 

Converted  functions  called  by  the  application  program  to  use 
a  structure  for  ease  of  use. 

3.0 

21  October  1987 

Theodore  H.  Barrow 

Removed  functions  for  reading  from  and  writing  to  the  shared 
memory  segment  by  the  application  program. 

4.0 

31  May  1988 

Theodore  H.  Barrow 

Added  functions  broadcas t_in t o_segmen t  and 

send_socke t_f rom_segmen t  for  broadcasting  over  datagram  socket 

******************************************************** 


* 
* 
* 
* 

* 
* 
* 

* 
* 
* 
* 
* 

* 
* 
* 

* 
* 
* 
* 
* 
* 
* 

* 
* 
* 
* 

* 
* 
* 
♦Version*   Date   *  Author  * 

*  *     Change  Description 

********************************************************** 

*  *         *  * 

*  * 

******************************* **********************************************^ 


RECORD  OF  CHANGES 


*  Affected    *Reqd 

*  Modules    *Vers 

******************** 

*  * 

*  * 


111 


support.c 

#include  "shared. h" 

#  i  nc lude  <gl . h> 

#include  <bsd/sys/ types . h> 

^include  <sy s / socke t . h> 

#include  <bsd/ne t inet / in . h> 

#include  <bsd/ne tdb.h> 

/*  the  following  routine  sets  up  buffer  area  */ 

ini  t_shared_buf f er ( segment ) 

char  "segment;    /♦  pointer  to  the  shared  segment  */ 

( 

free_sender(  segment  ); 

f ree_recei ver (  segment  ); 

♦(segment  +  PROTO&LHOLDOFFSET  +  9)  -  '\0'; 


/♦  the  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
valid. 

•/ 

f ree_ sender ( segment ) 

char  "segment;    /*  pointer  to  the  shared  segment  */ 

I 

/♦  the  following  line  zeroes  the  first  four  bytes  of  the  sender  part 
of  the  shared  memory  segment,  'segment'  is  a  character  pointer. 
I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 
*/ 
♦((long  ♦)segment  +  ^SEMMIOFFSET)  =  0; 


/♦  this  following  routine  writes  zeroes  at  the  top  of  the 

shared  segment  indicating  that  the  segment  data  is  no  longer 
valid. 

•/ 

free_receiver( segmen  t ) 

char  ♦segment;    /♦  pointer  to  the  shared  segment  ♦/ 

{ 

/♦  the  following  line  zeroes  the  first  four  bytes  of  the  receiver  part 
of  the  shared  memory  segment,  'segment'  is  a  character  pointer. 
I  coerce  it  into  a  long  integer  pointer  and  then  write  a  zero. 

♦((long  ♦)segment  +  WIECEIVEROFFSET)  =  0; 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 
*/ 

in t  rece  i ve r_has_da t a( instructure) 
Machine  *  ins t rue t ure ;   /*  includes 

char  * i ns t rue ture . segment    a  pointer  to  the  shared  segment  */ 


I 


f(*((long  *)inst ructure->segment  +  ^RECEIVEROFFSET)  >  0) 
return(TRUE); 
else 

return(FALSE) ; 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  non-zero. 
•/ 

int  sender_has_da t a( segment ) 

char  *segment;    /*  pointer  to  the  shared  segment  */ 

I 

f(*((long    *)segment    +  WSErOEROFFSET)    >    0) 
return(TRUE) ; 
e  1  se 

return(FALSE) ; 
) 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  less  than  zero. 
*/ 

int  recei ver_should_die( segment ) 

char  "segment;    /*  pointer  to  the  shared  segment  */ 

( 

if(*((long  *)segment  +  ^RECEIVEROFFSET)  <  0) 

return(TRUE); 

} 
else 

( 

return(FALSE); 

I 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  less  than  zero. 
♦/ 

int  sender_should_die( segment ) 

char  "segment;    /*  pointer  to  the  shared  segment  */ 

{ 

if(*((long  *)segment  +  ^SEhDEROFFSET)  <  0) 

I 

return(TRUE) ; 

) 
else 

I 

return(FALSE) ; 

I 
} 
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/*  the  following  routine  tests  the  first  4  bytes  of  the  receiver 

segment  to  see  if  they  are  non-zero. 
*/ 

int  rece iver_i s_free( segment ) 

char  ^segment;    /*  pointer  to  the  shared  segment  */ 

I 

if(*((long  *) segment  +  WIECEIVEROFFSET)  ==  0) 

( 

return(TRUE) ; 

I 
else 

I 

return(FALSE) ; 

} 
} 


/*  the  following  routine  tests  the  first  4  bytes  of  the  sender 

segment  to  see  if  they  are  non-zero. 

it  uses  an  input  structure  since  called  by  main  program 
•/ 

int  sender_i s_f ree( ins t rue t ure ) 
Machine  *  ins t rue t ure ;   /*  includes 

char  *ins t rue ture . segment    a  pointer  to  the  shared  segment  */ 


I 


if(*((long    *)instructure->segment    +  WSErOEROFFSET)    ==  0) 

I 

return(TRUE) ; 

I 
else 

( 

return(FALSE)  ; 

} 
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/*  the  following  routine  reads  on  the  input  socket  into  the  receiver  segment.*/ 

read_socke 1 _ i  n  t  o_s egmen  t ( socket , segment  ) 

int  socket;    /*  a  socket  descriptor  */ 

char  "segment;  /*  a  ptr  to  the  shared  segment  */ 

I 

long  nbytes;    /*  the  number  of  bytes  read  in  */ 
char  templLARGESTREAD] ; 

/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment . 

•/ 

nbytes  =  r  e  ad  (  socket  ,  temp,  LARGESTREAD)  ; 

if(nbytes  <=  0) 

I 

/*  the  following  routine  calls  are  commented  out  for  the  following 
reason : 

nbytes  <=  0  means  that  the  socket  has  been  broken. 

This  routine  is  called  by  the  receiver  process  so  the  only 
intelligent  thing  to  do  is  to  terminate  the  receiver  process, 
i.e.  call  ex  i t .  . . 

per ror( " read" ) ; 

printf  ("READ_SOCKET_Irm>_SEGMENT:  number  of  bytes  read  =  %d\n"  .nbytes ) ; 

shutdown(  socket,  2  ); 
close(  socket  ); 
exit(l); 

I 

/*  copy  the  data  into  the  shared  segment  */ 
memcpy(( segment  +  RECEIVEROFFSET  +  4) , t emp.nby tes ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 
♦((long  +)segment  +  RECEIVEROFFSET)  =  nbytes; 
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/*  the  following  routine  writes  the  data  from  the  sender  side 
of  the  shared  segment  to  the  socket  */ 

wr  i  t e_socke t_f rom_  segment (socket , segment ) 

int  socket;    /*  socket  descriptor  */ 

char  *segment;    /*  pointer  to  the  shared  segment  */ 

( 

long  nbytes;    /*  the  number  of  bytes  to  write  */ 
char  temp[LARGESTREAD]  ; 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment  . 

*/ 

memcpy( temp, ((char  *)segment  +  SENDEROFFSET  +  4), 

*  (  ( 1  ong  * )  segmen  t  +  WSENDEROFFSET) )  ; 

/*  write  the  data  to  the  socket  */ 

nbytes  =  wr  i  t  e(  socke  t  ,  t  emp,  *((long  *)  segment  +  WSENDEROFFSET) ) ; 

if (nbytes  <=  0  I  I  nbytes  !=  *((long  *) segment  +  WSENDEROFFSET) ) 
I 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 

sender  process . 

pe  r ror ( "wr  i  t e" ) ; 

printf  ("\MUTE_SOCKET_FRCM_SECaCNT:  number  of  bytes  written  =  %d\n" .nbytes ) ; 

print  f(  "Number  of  bytes  in  shared  segment  =  %d\n" , *( ( long  *)segment  +  WSErOEROFF 

*/ 

shutdown!  socket,  2  ); 
c lose (  socke  t  ) ; 
exi  t(l) ; 
} 

/*  free  the  sender  segment  */ 
free_sender( segment ) ; 


128 


support.c 

/*  The  following  routine  receives  on  the  input  datagram  socket. 

If  the  message  matches  the  mname  and  portnum  it  is  copied  into  the 
receiver  area  of  the  shared  memory  segment. 

0  is  returned  if  the  message  does  not  match  mname  and  portnum, 
the  number  of  bytes  read  is  returned  if  it  does  match.  */ 

int  broadcas t_into_ segment (socket , segment  ,  mname , portnum) 

int  socket;    /*  a  socket  descriptor  */ 

char  "segment;  /*  a  ptr  to  the  shared  segment  */ 

char  mname [ ] ;   /*  machine  name  of  broadcaster  */ 

long  portnum;   /*  port  number  of  broadcaster  */ 

{ 

long  nbytes;  /*  the  number  of  bytes  read  in  */ 

char  t emp [ LARGESTREAD ) , 

int  flags  =  0;  /*  flags  =  0  indicates  none  set  */ 

struct  sockaddr_in  who;  /*  Internet  structure  for  message  sender  address  */ 

int  wholen;  /*  length  of  received  address  struct  who  */ 

struct  hostent  *b roadcas t e r ;    /*  pointer  to  structure  with  info  on 

broadcaster  */ 

static  long  broadcas t_address ;  /*  address  of  broadcaster  */ 

static  short  broadcas t_por t ;    /*  port  of  broadcaster  */ 

static  Boolean  first  time  =  TRUE; 

/*  read  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segment.  This  also  allows  checking  for  match  with  desired  broadcaster. 

•/ 

nbytes  =  recvfrom(  socket,  temp,  LARGESTREAD.  flags, 

(struct  sockaddr  *)&who,  Awholen  ); 

if(nbytes  <=  0) 

i 

perror("recvfrom:"); 

I 
else 

I 

i  f (  f  i  r  s  1 1  ime  ) 

( 

/*  determine  desired  broadcaster  address  and  port  */ 

broadcas t_port  =  ht ons ( ( shor t )por tnum) ; 

broadcaster     =  (struct  hostent  * )gc t hos t byname (  mname  ) ; 

bcopy(  broadcas ter->h_addr ,  (char  *  )&broadcas t_address , 
broadcas ter ->h_length  ); 


if(  (broadcas t_address  ==  who . s in_addr . s_addr ) 
(broadcas t_port     ==  who. sin_por t )  ) 
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/*  copy  the  data  into  the  shared  segment  */ 
memcpyU segment  +  RECEIVEROFFSET  +  4) , temp.nby tes ) ; 

/*  set  the  number  of  bytes  in  the  shared  segment  */ 
♦((long  *)segment  +  WIECEIVEROFFSET)  =  nbytes; 

) 
else 

I 

nbytes  =  0; 

/*  Set  nbytes  to  0  so  return  of  function  indicates  no  match  */ 
) 
I 

re  t urn(  n by t es  ) ; 
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/*  the  following  routine  sends  the  data  from  the  sender  side 
of  the  shared  segment  to  the  socket  for  broadcast  */ 

send_socke t_f rom_  segment (socket , port num,  segment ) 
int  socket;  /*  socket  descriptor  */ 

long  portnum;     /*  port  number  of  broadcaster  */ 
char  ^segment;    /*  pointer  to  the  shared  segment  */ 

I 

long  nbytes;    /*  the  number  of  bytes  to  write  */ 

char  temp[LARGESTREAD]  ; 

short  broadcas t er_por t ; 

static  Boolean  first  time  =  TRUE; 

static  struct  sockaddr_in  network  =  {  AF_INET  );  /*  structure  for  broadcast 

address  */ 

i  f (  f  i  r  s  t  t  ime  ) 

( 

broadcaster_port  -  IPPORT_RESERVED  +  portnum; 

/*  Set  up  broadcasting  address  structure  */ 

ne  twork  .  s  in_f  ami  ly       =  AF_INET; 

network. sin_addr. s_addr  =  h tonl ( INAIX>R_BROADCAST) ; 

ne twork . s in_port         =  h tons(broadcas t er_por t ) ; 

first  time  =  FALSE; 

I 

/*  copy  the  data  into  a  temporary  array  to  avoid  segment  protection 
violation  since  the  socket  does  not  share  with  the  shared  memory 
segmen  t  . 

•/ 

memcpy( temp, ((char  *)segment  +  SENDEROFFSET  +  4), 

♦((long  *)  segment  +  WSENDEROFFSET) ) ; 

/*  broadcast  the  data  through  the  socket  * / 

nbytes  =  sendto(  socket,  temp,  *((long  *)segment  +  W5ENDEROFFSET)  ,  0, 

(struct  sockaddr  *)&network,  s i zeof(ne twork)  ); 

if(nbytes  <=  0  I  I  nbytes  !=  *((long  *)segment  +  ^SENDEROFFSET) ) 

/* 

This  error  indicates  the  socket  is  broken.  Just  exit  the 

sender  process. 

*/ 

per ror ( "wr i  t e" ) ; 

print  f("WUTE_SCCKET_FROM_SEavENr:  number  of  bytes  written  =  %d\n"  .nbytes )  ; 
print f(  "Number  of  byles  in  shared  segment  =  %d\n" , *( ( long  *)segment  +  W5ENDEROFFSET) ) 
shutdown(  socket,  2  ); 
c  lose (  socke  t  ) ; 
exi 1(1); 
I 

/*  free  the  sender  segment  */ 
free_sender( segment ) ; 
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/*  the  following  routine  deletes  the  sender  by  writing 

a  negative  byte  count  into  the  shared  segment 

and  then  waking  up  the  sender. 
*/ 

kill_sender( segment , sends  em) 

char  ♦segment;    /♦  ptr  to  the  segment  */ 

int  sendsem;  /*  semaphore  to  the  sender  */ 

( 

/*  write  a  negative  number  into  the  byte  count  field.  ♦/ 
♦((long  ♦) segment  +  WSETOEROFFSET)  =  -1; 

/*  at  this  point,  we  should  send  a  wakeup  to  the  sender  program, 
the  sender  will  read  the  bad  byte  count  and  exit. 

*/ 

V(  sendsem)  ; 


/*  the  following  routine  deletes  the  receiver  by  writing 

a  negative  byte  count  into  the  shared  segment 

and  then  waking  up  the  receiver. 
*/ 

kill_receiver( segment , receives  em) 

char  ♦segment;    /*  ptr  to  the  segment  */ 

int  receivesem;  /*  semaphore  to  the  receiver  ♦/ 

I 

/♦  we  do  not  wait  until  the  receiver  segment  is  free  here 
as  the  process  that  calls  this  routine  should  already 
have  read  the  last  piece  of  data. 

•/ 

/♦  write  a  negative  number  into  the  byte  count  field.  ♦/ 
♦((long  ♦) segment  +  WRECEIVEROFFSET)  =  -1; 

/♦  at  this  point,  we  should  send  a  wakeup  to  the  receiver  program, 
the  receiver  will  read  the  bad  byte  count  and  exit. 

*/ 

V(  rece  ivesem) ; 
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APPENDIX  B  -  H  EXPLORER  MODULE  DESCRIPTIONS 

All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 

1.     Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application's  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  iris 

(defun  iris  (x)      ;where  x  is  number  of  iris  machine  desired 

b.  start-iris 


(defmethod    (conversat ion-wi th- i r is      start-iris) 
() 


c.  get- iris 

(defmethod  (conversat ion-wi th- iris  :get-iris) 
() 

d.  put-iris 

(defmethod  (conversat ion-wi th- i r i s  :put-iris) 
(obj  ec  t ) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  (conver t -number- to- s t ring  object)) 

((equal  (type-of  object)   fixnum)  (convert-number-to-string  object)) 
((equal  (type-of  object)  'float)  (conver t -number  -  to- s t r ing  object)) 
((equal  (type-of  object)  'string)  object) 
(t  ,ferror")  )) 


e.      stop-iris 


(defmethod    (conversat ion-wi th- ir is    :stop-iris) 
() 


reuse-iris 


(defmethod  (conversat ion-wi th- i r is  :  reuse- i r  1  s  ) 
() 
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2.      Code  and  Description 


(defmacro  loopfor  (var  init  test  expl  Aoptional  exp2  exp3  exp4  expS) 
'(prog  () 

(setq  , var  ,  ini  t ) 

tag 

,  expl 

,  exp2 

,exp3 

,exp4 

,exp5 

(setq  , var  ( 1+  , var ) ) 

(if  (=  ,var  ,test)  (return  t)  (go  tag))  )  ) 

(defun  convert-number-to-string  (n) 
(pr inc -  to- s t r ing  n)  ) 

(defun  conver t - s t r ing- to- integer  (str  &optional  (radix  10)) 
(do  ((j  0  (+  j  1)) 

(n  0  (+  (*  n  radix)  (digi t -char-p  (char  str  j)  radix)))  ) 
((=  j  (length  str))  n)  )  ) 

(defun  find-per iod- index  (str) 
(catch  ' exi t 

(do times  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  "."  0)) 
(throw  'exit  x)  )  )  )  ) 

(defun  ge t - lef t s ide-of -  real  (str  &optional  (radix  10)) 
(do   ((j  0  (1+  j)) 

(n  0  (+  (*  n  radix)  (digi t -char-p  (char  str  j)  radix)))  ) 

((or  (null  (digi t -char-p  (char  str  j)  radix))  (=  j  (length  str)))   n)  )  ) 

(defun  ge t -  right side-of- real  (str  &optional  (radix  10)) 
(do  ((index  (1+  ( find-per iod- index  str))  (1+  index)) 
(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  (digi t -char-p  (char  str  index)  radix))))  ) 
((=  index  (length  str))  n)  )  ) 

(defun  conver t - s t r ing- to- real  (str  Aoptional  (radix  10)) 

(-1-  (float  (ge  t  -  lef  t  s  ide-of  -  real  str  radix))  (ge  t  -  r  ight  s  ide-of  -  real  str  radix))  ) 

(defvar  * tcp-handler 1*  (send  ip : : * t cp-handl er*  :get-port)) 
(defvar  * tcp-handl er2*  (send  ip ::* tcp-handler*  :get-port)) 


(defvar  * i ri s 1 -por t 1*  1027) 

(defvar  *i r i si -por t2*  1026) 

(defvar  * i r i s  1  -  address*  3221866502) 

(defvar  * i r i s2- address*  3221866504) 

(defvar  * ir i s3- address*  3221866505) 

(defvar  *des t -address*   nil) 


;  this  is  the  send  port 
;  this  is  the  receive  port 


;  the  tcp-ip  or  internet  address 
;  look  in  network  configuration 


(defun  iris  (x) 

(cond  ((equal  x  1)  (setq  *des t - addre s s*  *i r i s 1  -  address*) ) 

((equal  x  3)  (setq  *des t -  address*  *i r i s3- addres s*) ) 

(t  (setq  *des t -address*  *i r i s2- address* ) )  )  ) 

(defflavor  conver sat ion-wi  th- i r i s  (( t a lking-por t -number     * i r i s 1 -por t 1* ) 

(listening-port -number   *irisl-port2*) 
(talking-port  * tcp-handler 1*) 

(listening-port  * tcp-handler2*) 

(destination  *des t -address*)  ) 
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() 

:  se 1 1 able- 
:  ini  t able- 


:get table- instance-variables 
instance-variables 
instance-variables  ) 


(defmethod  ( conve r s a t i on-wi  t h - i r i s  :start-iris) 

() 
(progn 
(send  talking-port  :open 
: ac  t  i ve 

talking-port -number 
destination 


tcp  will  begin  the  procedure  to  establish 
connection   (default   vs  :passive) 
port  number  of  destination  host 
machine  name  or  address  if  blank  and 
in  :passive  mode  local  machine  waits  for 
connec  t  ion 
set  max  seconds  before  read  request  times  out 

; ipass  i ve 


30  ) 
(send  listening-port  :open 

: ac  t  i ve 

listening-port -number 

des  t  ina t ion 

30  ) 
'"A  conversation  with  the  iris  machine  has  been  established"  )  ) 


iris 


reuse -iris) 


(defmethod  (conver sat ion-wi th- 

() 
(setq  * t cp-handl er 1*  (send  ip :: *t cp-handler*  :get-port) 
* t cp-hand ler2*  (send  ip :: *t cp-handler *  :get-port) 
talking- port    *tcp-handlerl* 
listening-port  * t cp-handler2*  )  ) 

(defmethod  (conver sat ion-wi  th- i r i s  :get-iris) 
() 
(let*  ((typebuffer    "  ") 
(lengthbuffer  "     ") 
(buffer        "  ") 
(buffer-length  1)  ) 
(progn 

(send  listening-port  :receive 
t  ypebuf f er 
buffer  - 1 engt h 
30 

:  wa  i  t  ) 
(send  listening-port  :receive 
lengthbuffer 
4 

30 

:  wa  i  t  ) 
(setq  buf fer -  length  ( conver t - s t r ing- to- in  lege r  lengthbuffer)) 
(setq  buffer  (make-string  buf fer- length  : ini t i al -element  (character 
listening-port  : receive 


(  se 


:i 


32))) 


buffer 
buffer- length 
30 

:  wa  i  t  ) 
(cond  ( (equal 
( (equal 
( ( equal 
(t  nil) 


typebuffer 
typebuffer 
typebuffer 
)  )  )  ) 


"I")  (conver t - s t r ing- t o- in teger  buffer)) 
"R" )  (conver t - st ring- to- real  buffer)) 
"C")  buffer) 


:  pu l - i  r  i  s  ) 


(let 


(defme  thod  (conversation-with-iris 
(obj  ec  t ) 
((buffer  (cond 

((equal  (type-of  object)  'bignum)  (conver t -number  -  to- st ring  object)) 

((equal  (type-of  object)  ' f ixnum)  (conver t -numbe r - t o- s t r i ng  object)) 
((equal  (type-of  object)  'float)  (conver t -number  -  to- s t r ing  object)) 
((equal  (type-of  object)  'string)  object) 


(t  'error") 
(buffer- length 


)) 
(length  buffer)) 
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(typebuffer      (cond  ((equal  (type-of  object)  'bignum)  "I") 
((equal  (type-of  object)  "fixnum)  "I") 
((equal  (type-of  object)  'float)  "R" ) 
((equal  (type-of  object)  'string)  "C" ) 
(t  *Cm)    )) 
( lengthbuf f er    (convert -number-to-string  buffer- length) ) 
( *loopvar i able*  0)  ) 
(progn 

(send  talking-port  : send 
typebuffer 
1 

nil 
nil  ) 
(if  (=  (length  lengt hbuf f er )  4) 
(send  talking-port  : send 
lengthbuf fer 
4 

nil 
nil  ) 
(progn 
(loopfor  *loopvar i abl e*  (length  lengthbuf fer )  4 

(send  talking-port  : send  "5"  1  nil  nil)  ) 
(send  talking-port  :send  lengthbuffer  (length  lengthbuf fer )  nil  nil)  ) 
(send  talking-port  : send 
buffer 

buffer  -  length 
t 
nil  )  )  )  ) 

(defmethod  (converse t ion-wi  t h- i r i s  :stop-iris) 

() 
(progn  (send  talking-port  .close)  (send  listening-port  :close))  ) 
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All  functions,  methods,  and  flavor  are  contained  in  file  irisflavor.lisp. 

1 .      Calling  Protocols 

The  module  contains  functions,  methods,  and  a  flavor  that  are  intended  for  the 
application's  use.  It  also  contains  a  macro  and  functions  that  are  used  internally.  The 
parameters  for  externally  accessible  functions  and  methods  are  described  below. 

a.  select-host 

(defun  select-host    (host-name) 

b.  start-iris 

(defmethod  (:start-iris  conversat ion-wi th- i ri s ) 
() 

c.  get-iris 

(defmethod   (:get-iris   conversat ion-wi th- iri s) 

() 

d.  put- iris 

(defmethod  (.put-iris  conversa t ion-wi  th- i r i s  ) 
(obj  ec  t  ) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  (conver t -number  -  to- s t ring  object)) 

((equal  (type-of  object)  ' fixnum)  (conver t -number- to- s t ring  object)) 
((equal  (type-of  object)  * s ingle- float )  (conver t -number- to- s t ring  object)) 
((equal  (type-of  object)  'string)  object) 
(t  ''error")  )) 


e.      stop-iris 


(defmethod   (:stop-iris   conversat ion-wi th- iris) 
() 


f.      reuse-iris 


(defmethod  (:reuse-iris  conversat ion-wi th- i r is) 
() 
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2.      Code  and  Description 


;;;  -*-  Mode:  LISP;  Syntax:  Common- 1 i sp;  Package:  USER  -*- 

;  handy  macro  to  have  in  the  send  message  farthur  down 

(defmacro  loopfor  (var  init  test  expl  &optional  exp2  exp3  exp4  expS) 
'(prog  () 

(setq  ,var  ,init) 
tag 

•  expl 

.  exp2 

,  exp3 

,  exp4 

,  exp5 

(setq  , var  (1+  , var ) ) 

(if  (=  ,var  .test)  (return  t)  (go  tag))  )  ) 

(defun  conver t -number- to- s t r ing  (n) 
(pr inc- to- s t r ing  n)  ) 

(defun  conver t - s t r ing- to- in teger  (str  &optional  (radix  10)) 
(do  ((j  0  (+  j  1)) 

(n  0  (+  (*  n  radix)  (digi t -char -p  (char  str  j)  radix)))  ) 
((  =  j  (length  str))  n)  )  ) 

(defun  find-per iod- index  (str) 
(catch  'exit 

(dotimes  (x  (length  str)  nil) 

(if  (equal  (char  str  x)  (char  "."  0)) 
(throw  'exit  x)  )  )  )  ) 

(defun  ge t -  left s ide-of- real  (str  &optional  (radix  10)) 
(do   ((j  0  (1+  j)) 

(n  0  (+  (*  n  radix)  (digi t -char-p  (char  str  j)  radix)))  ) 

((or  (null  (digi t -char -p  (char  str  j)  radix))  (=  j  (length  str)))   n)  )  ) 

(defun  ge t - r ight s ide-of -  real  (str  &optional  (radix  10)) 
(do  ((index  (1+  ( find-per iod- index  str))  (1+  index)) 
(factor  0.10  (*  factor  0.10)) 

(n  0.0  (+  n  (*  factor  (digi t -char-p  (char  str  index)  radix))))  ) 
((=  index  (length  str))  n)  )  ) 

(defun  conver t - s t ring- to- real  (str  &optional  (radix  10)) 

(+  (float  (ge t -  left s ide-of -  real  str  radix))  (ge t - r ight s ide-of -  real  str  radix))  ) 


(defvar  *iris-portl*  1027) 

(defvar  *iris-port2*  1026) 

(defvar  *  local  - 1 alk-port *  1500) 

(defvar  *  local  - 1 i s ten-por t *  1501) 


this  is  the  send  port 

this  is  the  receive  port 

this  is  the  local  send  port 

this  is  the  local  receive  port 


(defflavor  conver sa t ion-wi  th- i r i s  (( t alki ng-por t -number       * i r i s-por 1 1* ) 

(listening-port -number     *iris-port2*) 
(local- talk-port -number    *local-talk-port*) 
(local-listen-port -number  *local-listen-port*) 
( t  alking- s  t  ream) 
(listemng-st  ream) 
(des t inat i on-hos t -obj ec t )  ) 
() 
: ini t able- ins t ance- var iabl es  ) 

(defmethod  ( : in i t -des t inat ion-hos t  conver sat ion-wi  th- i r i s ) 
(name-of -hos  t ) 
(setf  des t inat ion-hos t -obj ec t  (ne t :par se-hos t  name-of -hos t ) )  ) 
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(defmethod  (:start-iris  conversat ion-wi  th- i r i s ) 

() 
( set  f  talking- st  ream 

( t cp : open- tcp-stream  destination-host-object 
talking-port -number 
local  - t alk-port -number  )  ) 
(setf  1 i s t ening- s t ream 

( t  cp : open  - tcp- st  ream  dest  inat  ion-host -object 
listening-port -number 
local  - 1 i s ten-por t -number  )  ) 
"A  conversation  with  the  iris  machine  has  been  established"  ) 

(defmethod  ( : reuse-iris  conversat ion-wi  th-  i r i s  ) 
() 
) 

(defun  read-string  (stream  num- chars) 
(let  ((out -st ring  "")) 
(dotimes  (i  num-chars) 

(setf  out-string  (string-append  out-string  (read-char  stream)))  ) 
out  - s  t  r  ing  )  ) 

(defmethod  (:get-iris  conversat ion-wi  th- i r i s  ) 
() 
(let*  ((typebuffer    "  ") 
( lengthbuf f er  "     ") 
(buffer        "  ") 
(buffer-length  1)  ) 
(progn 

(setf  typebuffer 

(read-string  1 i s tening- s t ream  1)  ) 
(setf  lengthbuffer 

(read-string  1 i s tening- s t ream  4)  ) 
(setf  buf fer -  length 

(conver t -  8 t r ing- to- in t eger  lengthbuffer)  ) 
(setf  buffer 

(read-string  1 i s teni ng- s t ream  buf fer -  length)  ) 

(cond  ((equal  typebuffer  "I")  (conver t - s t ring- to- in t eger  buffer)) 
((equal  typebuffer  "R" )  (conver t -  8 t r ing- to- real     buffer)) 
((equal  typebuffer  "C" )  buffer) 
(t  nil)  )  )  )  ) 

(defvar  *step-var*  0) 

(defun  my-wr  i te- 8 t r ing( s t r ing  stream) 
(let*  ((num-chars  (length  string))) 
(dotimes  (i  num-chars) 

(write-char  (aref  string  i)  stream)  )  )  ) 

(defmethod  (:put  iris  conver sat ion-wi  th- i ri s  ) 
(object) 
(let*  ((buffer  (cond 

((equal  (type-of  object)  'bignum)  ( conver t -number  -  to- s t ring  object)) 

((equal  (type-of  object)  'fixnum)  (conver t -number  -  to- s t r ing  object)) 
((equal  (type-of  object)  ' s ingle- f loat )  (conver t -number  -  to- s t r ing  object)) 
((equal  (type-of  object)  'string)  object) 
(t  ''error")  )) 

(buf fer -  length   (length  buffer)) 

(typebuffer      (cond  ((equal  (type-of  object)  'bignum)  "I") 
((equal  (type-of  object)  'fixnum)  "I") 
((equal  (type-of  object)  ' s ingle  -  float )  "R" ) 
((equal  (type-of  object)  'string)  "C" ) 
(t  *C")  )) 

(lengthbuffer    (conver t -number- to- s t r ing  buf fer- length) )  ) 
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(progn 

(my-wr  i t e-s t ring  typcbuffer  t alking- s t ream) 
(send  t alk ing- s t ream  : force-output ) 
(if  (=  (length  lengthbuf f er )  4) 

(wr i t e- s t ring  lengthbuffer  talking- 8 t ream) 
(progn 

(Toopfor  *step-var*  (length  lengthbuffer)  4 
(wr  i te- s t r ing  "0"  talking- s t ream)  ) 

(my-wr  i te- string  lengthbuffer  t alking- s t ream)  )  ) 
(send  t alking- s t ream  : force-output ) 
(my-wr  i te- s t ring  buffer  t alking- s t ream) 
(send  talking- s t ream  : force-output )  )  )  ) 

(defmethod  (:stop-iris  conver sat ion-wi th- i r i s) 

() 
(progn  (send  t al king- s t ream  :close) 
(send  1 i s t ening- s t ream  :close)  )  ) 

(defun  select-host  (host-name) 

(send  talk  :  ini t -des t inat ion-hos t  host-name)  ) 
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1.      gprog.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from   iris2.   It  must  be  run  in  conjunction  with 

gprog2.c  to  function  properly,  as  the  port  assignments  are  hardcoded.   Since  it  is  the 

server  program,  it  must  be  started  before  gprog2.c. 

b.  Code  and  Description 

/*  this  is  file  gprog.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  SERVER  side  program  and  runs  first!!!. 

*/ 

#inciude  "shared. h" 
#inc lude  "gl . h" 
#include  "device. h" 

main( argc , argv) 

int  argc;    /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


I 


Machine  remot  emachine ;  /*  structure  for  remote  machine  */ 

char  other_machine[50] ;  /*  name  of  other  machine  */ 

char  mybuf fer  [LARGESTREAD] ;  /*  received  data  */ 

char  ou t going [LARGESTREAD] ;  /*  outgoing  message's  buffer  */ 


int  mybufferl[LARGESTREAD/INTEGER_SIZE] 
int  ou t go ingl [LARGESTREAD/ INTEGER_SIZE] 
float  mybuffer2[LARGESTREAD/FLQAT_SIZE] 
float  outgoing2[LARGESTREAD/FLQAT_SIZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer  */ 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  */ 


long  noutgoing;  /*  size  of  the  outgoing  message  */ 
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char  temp[10];  /*  temp  array  used  to  make  outgoing  message  */ 

long  count  =  0;  /*  message  counter  */ 

char  received_type( ) ; 

char  type_received; 

int  element s_received; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2) 

I 

pr int f ( "GPROG:  incorrect  argument  count!   use  gprog  <alias>\n"); 
exit(l); 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

i  f (  argc  ==  2  ) 

I 

strcpy(  other_machi ne ,  "npscs-"  ); 
strcat(  other_machine ,  argvflj  ); 

} 
else 

strcpy(  other_machine ,  "npscs - i r i s 1"  ); 

/*  create  a  path  to  a  particular  machine  (irisl  default)  */ 
/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use. 
the  fifth  argument  indicates  whether  the  processes  should 

act  as  a  server  or  a  client, 
the  sixth  argument  is  the  returned  pointer  to  the  structure 
r  emo  t  etna  chine. 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sendsem  id, 
and  the  returned  receivesem  id. 
the  seventh  argument  is  the  amount  of  freespace  desired  for  dynamic 
memory  allocation  during  execution  of  the  program. 
•/ 
dynamicmach i  nepa  t  h( 1 , ot her_mach i ne ,1,2, "server"  ,&remotemachine , 2000000) ; 

/*  the  loop  for  polling  the  shared  segment  */ 
while(TRUE) 

I 

/*  make  an  outgoing  message  */ 
strcpy(outgoing, "GPROG  ORIGINATED  MESSAGE:  "); 

count  =  count  -  1; 

ou t goi ng  1  [0  |  =  count; 

noutgoing  =  s t rlen(out going) ; 

outgoing2[0]  =  count; 

/*  is  there  data  in  the  shared  segment?  */ 
i  f ( receive r_has_dat a(&remot emac hi ne) ) 

I 

type_recei ved    =    recei ved_t ype  (Areniot  emachi  ne  ) ; 


142 


) 


gprog.c 

printf("The  message  received  by  GPROG  is  of  type  %c   \n"  , 
t ype_recei ved) ; 

switch  ( type_recei ved) 

{ 

case  CHARACTER_ARRAY_TYPE: 

e lemen t 8_recei ved  =  number_rece i ved(&remot  emachine ) ; 

printf("The  message  received  by  GPROG  is  %d  elements  long!\n", 
element  s_received); 

read_charact er s (Aremot emachine ,  mybuffer,  element s_recei ved) ; 
break ; 

case  INTEGER_TYPE : 

read_in t ege r (Aremot  emachine  .mybuffer 1 ) ; 
break ; 

case  PLOAT_TYPE: 

read_ float (Aremot emachine .mybuffer 2) ; 
b  r  e  ak ; 

I 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 

pr int f ("GPROG  has  received  the  following  data:\n"); 

switch  ( type_recei ved) 

I 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  element s_received ;  i+=l) 

I 

pr int  f ( "%c" .mybuffer [ i ] ) ; 

I 
break ; 

case  INTEGERJTYPE : 

print f("%d", mybuffer 1[0]); 
break ; 

case  FLOAT_TYPE: 

print f("%f" .mybuf fer2[0]); 
break; 

I 

print f(*\n"); 


/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

i  f ( sender_i  s_f ree( Aremot  emachine ) ) 

I 

if((j  %  3)  ==  0) 

wr  i te_character s (Aremot  emachine .outgoing, noutgoing); 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sender_i s_free(Aremot  emachine )  )  /*  do  nothing  */  ; 

if((j  %  3)  ==  1) 

wr i  te_in t ege r (Aremot  emachine , out  going 1) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_free(Aremot  emachine)  )  /*  do  nothing  */  ; 

if((j  %  3)  ==  2) 

wr  i  t  e_f loa  t (Aremot  emachi ne , ou t going2) ; 


e  1  se 


++j; 
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/*  assume  socket  connection  broken  */ 
pr in t f( "Sender  wasn't  freel   Termina t ing. . . \n" ) ; 
break ; 


}    /*  endif  while  TRUE  ♦/ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 

del e  t emach  i  nepa  th (&remot emachine ) ; 
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2.      gprog2.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  direct  connect  protocol.  By  command  line 
argument,  another  machine  to  receive  direct  connect  messages  from  can  be  specified. 
The  default  is  to  receive  messages  from   irisl.    It  must  be  ran  in  conjunction  with 

gprog.c  to  function  properly,  as  the  port  assignments  are  hardcoded.    Since  it  is  the 

client  program,  it  be  started  after  gprog.c  is  ready  for  it. 

b.  Code  and  Description 

/*  this  is  file  gprog2.c 

It  is  a  sample  top  level  graphics  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

This  is  the  CLIENT  side  program  and  runs  second!!!. 

*/ 

#include  "shared. h" 
#define  TRUE  1 

ma  in( argc , argv) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


( 


Machine  remot  emachine ;  /*  structure  for  remote  machine  */ 

char  other_machine [50] ;  /*  name  of  other  machine  */ 

char  mybuf fer [LARGESTREAD] ;  /*  received  data  */ 

char  out  going | LARGESTREAD 1 ;  /*  outgoing  message ' s  buffer  */ 


int  mybuf fer 1 [LARGESTREAD/ INTEGERJSIZE] 
int  ou t go ingl [LARGESTREAD/ INTEGER_SIZE] 
float  mybuffer2[LARGESTREAD/FLOAT_SIZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer  */ 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  */ 


long  noutgoing;  /*  size  of  the  outgoing  message  */ 

char  temp[ 10];  /*  temp  array  used  to  make  outgoing  message  */ 

long  count  =  0;  /*  message  counter  */ 

char  recei ved_t ype( ) ; 
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char  type_recei ved ; 

int  element s_received; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2) 

I 

pr in t f ( "GPROG2 :  incorrect  argument  count)   use  gprog2  <alias>\n"); 
exi  t(l) ; 

I 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

i  f (  argc  ==  2  ) 

I 

strcpy(  o t her_machine ,  "npscs-"  ); 
strcat(  other_machine ,  argv[l]  ); 

I 
else 

strcpy(  other_machine ,  "npscs - i r i s2"  ); 

/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  key  for  the  shared  memory  segment, 
the  second  argument  is  the  name  of  the  machine  to  connect  to. 
the  third  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fourth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  fifth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client, 
the  sixth  argument  is  the  returned  pointer  to  the  structure 

remot  ema  chine  . 

it  includes  the  pointer  to  the  shared  memory  segment, 

the  system  generated  shared  memory  id,  the  sendsem  id, 

and  the  returned  receivesem  id. 

•/ 

mach  i  nepa  t  h ( 1 , o t he r_machine ,2,1, "client" ,&remot  emachine ) ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
whi le(TRUE) 

( 

/*  make  an  outgoing  message  */ 

st  rcpy(  out  going,  "GPROG2  ORIGINATED  MESSAGE:  "  ) ; 

count  =  count  +  1; 

outgoingl[0]  =  count; 

noutgoing  =  s t rl en(out going) ; 

outgoing2[0]  =  count; 

/*  is  there  data  in  the  shared  segment?  */ 
if(receiver_has_dat  a (&remot  emachine ) ) 

I 
t ype_recei ved  =  rece ived_type(&remot emachine ) ; 

printf("The  message  received  by  GPROG2  is  of  type  %c  \n" , 
t ype_recei ved) ; 

switch  ( type_recei ved ) 

I 

case  CHARACTER_ARRAY_TYPE : 

e lemen t s_rece i ved  =  number_rece ived(&remot emachine  )  ; 
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printf("The  message  received  by  GPR0G2  is  %d   elements  longl\n", 
element  s_received); 

read_charac t er s (Aremot  emachine .mybuf f er , 
e lemen t  s_received) ; 
break; 

case  INTEGERTYPE : 

read_ integer (&remot emachine ,mybuf f er 1 ) ; 
break; 

case  FLQVTTYPE: 

read_ float (Aremot emachine , mybuf fer2) ; 
break; 

} 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
pr int f ( "GPROG2  has  received  the  following  data:\n"); 

switch  ( type_received) 

( 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  e lemen t s_rece ived ;  i+=l) 

I 

pr in tf("%c", mybuf fer[i]); 

) 
break; 

case  INTEGER_TYPE : 

pr int f("%d",  mybuf ferl[0]); 
break; 

case  FLOAT_TYPE: 

printf("%f" ,mybuffer2[0]); 
break; 


I 


print  f("\n" ) ; 


/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(8ender_i  s_free (Aremot emachine ) ) 

( 
if((j  %  3)  ==  0) 

wri te_char ac t er s(&remot emachine , out  going ,nou t going) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_f  ree(Aremot emachine )  )  /*  do  nothing  */  printf("2"); 

if((j  %  3)  ==  1) 

wr  i  te_integer  (Aremot emachine , outgo ingl) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_free(&remot emachine)  )  /*  do  nothing  */  printf("3"); 

if((j  %  3)  ==  2) 

write_float  (Aremot  emachine ,outgoing2); 

++j; 

I 
else 

( 

/*  assume  socket  connection  broken  */ 
pr int f( "Sender  wasn't  free!   Termina t ing . . . \n" ) ; 
break; 
I 
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/*  at  this  point,  you  can  do  the  rest  of  the  display  loop  */ 

}    /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 
de 1 e temachinepa th(&remot emachine ) ; 
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3.      prog.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  iris2.  It  must  be  run  in  conjunction  with  prog2.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog . c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 


#include  "shared. h' 
#define  TRUE  1 


main( argc , argv) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


Machine  remot emachinel ; 
Machine  remot  emachine2; 
char  o ther_machine [50] ; 
char  mybuf fer  [LARGESTREAD] ; 
char  ou t going [LARGESTREAD] ; 


/*  first  structure  for  remote  machine  */ 

/*  second  structure  for  remote  machine  */ 

/*  name  of  other  machine  */ 

/*  received  data  */ 

/*  outgoing  message's  buffer  */ 


int  mybuf  ferl  [LARGESTREAD/  INTEGERS  I ZE  ] 


int  out  go  ingl  [LARGESTREAD/ INTEGER_SIZE] 
float  mybuffer2[LARGESTREAD/FLOAT_SIZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 
long  noutgoing; 
char  t  emp  [10]; 


:eived  integer  data  */ 


/*  outgoing  integer  message's  buffer  */ 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  */ 

/*  size  of  the  outgoing  message  */ 

/*  temp  array  used  to  make  outgoing  message  */ 


long  count  =  0; 

char  rece i ved_type( ) ; 

char  type_rece i ved; 


/*  message  counter  */ 
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int  element s_rece ived; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2) 

I 

pr in t f ( "PROG:  incorrect  argument  count!   use  prog  <alias>\n"); 
exi t(l); 

} 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

if(  argc  ==  2  ) 

I 

strcpy(  ot her_machine ,  argv[l]  ); 

I 
else 

strcpy(  other_machine ,  "npsc s - i r i s2"  ); 

/*  create  a  pair  of  paths  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  receiver  or  a  broadcaster. 

the  seventh  argument  is  the  returned  pointer  to  the  structure 
r emo t ema chinel  or  r emo t ema c h i n e 2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 
the  system  generated  shared  memory  id,  the  sends  em  id, 
and  the  returned  receivesem  id. 
*/ 
dynanii  cmach  i  nepa  t  h  s  (  2  ,  1  ,  o  t  he  r_mach  i  ne  ,2,1,  "receive"  ,&remot  emachinel )  ; 

sleep(5);    /*  to  let  both  sides  set  up  receiving  channels  first  */ 

dyn  ami  cmach  inepaths(2, 1 .other  _mac hi ne , 4 , 3 , "broadcas  t "  ,&remot  emach  ine2) ; 

/*  the  loop  for  polling  the  shared  segment  limited  to  avoid  send  buffer 

overflow  */ 
whi le(TRUE) 

{ 

/*  make  an  outgoing  message  */ 
strcpy(outgoing,"PROG  ORIGINATED  NESS AGE:  "); 

count  =  count  +  1; 

ou f go i ng  1  [0]  =  count; 

noutgoing  =  s t r 1 en( ou t go i ng ) ; 

outgoing2[0]  =  count; 

/  *  is  there  data  in  the  shared  se  gme  n  t  ?  * / 
if(receiver_has_dat  a(&remot emach  i  ne 1 ) ) 

I 
type_rece i ved  =  rece i ved_t ype (&remot  emach i ne 1 ) ; 

printf("The  message  received  by  PROG  is  of  type  %c  \n" , 
t  ype_rece  ived) ; 

switch  ( type_recei ved) 
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case  CHARACTER_ARRAY_TYPE: 

e  1  erne  lit  s_reccived  =  numbe  r_rece  i  ved(&remot  emach  ine  1  )  ; 

printf("The  message  received  by  PROG  is  %d    elements  longl\n" 
element  s_received); 

read_ characters  (&remot  emach inel  ,mybuf f er , 
element  s_received); 
break; 

case  INTEGER_TYPE : 

read_integer (Aremot emach inel .mybufferl) ; 
break; 

case  FLOATJTYPE: 

read_float (Aremot emach inel ,mybuf f er2) ; 
break ; 

} 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
pr  i  11 1  f  (  "PROG  has  received  the  following  data:\n")  ; 

switch  ( type_rece ived) 

( 

case  CHARACTER_ARRAY_TYPE : 

for(i=0;  i  <  element s_received ;  i+=l) 

I 

print  f ( "%c" ,mybuf f er [ i ] ) ; 

} 
break ; 

case  INTEGER_TYPE : 

print f("%d",mybufferl[0]); 
break; 

case  FLOAT_TYPE: 

printf("%f  " .mybuf fer2[0] ) ; 
break; 


) 


print  f ( "\n" ) ; 


/♦  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(sender_i s_f ree  (Aremot  emach i ne2 ) ) 

I 
if((j  %  3)  ==  0) 

wr  i  te_charac  ter s (Aremot emach ine 2 , outgoing, nout going) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  I sende r_i s_f ree(Aremot emach i ne2 )  )  /*  do  nothing  pr in t f ( "2"  )* / 

if((j  %  3)  ==  1) 

wr i  te_integer  (Aremot emach ine2, outgoingl) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 
while(  ! sender_i s_f ree(Aremot emachine2)  )  /*  do  nothing  pr in t f ( "3" )*/ 

if((j  %  3)  ==  2) 

wr i  te_f loat  (Aremot  emach ine 2 ,outgoing2) ; 

/*  wait  until  message  sent  before  continuing  */ 

while(  ! sender_i s_f ree (Aremot emachine2)  )  /*  do  nothing  pr in t f ( "4" )*/ 

) 
else 


151 


prog.c 

/*  assume  socket  connection  broken  */ 
pr int f( "Sender  wasn't  free!\n"); 
break; 
I 

/*  at  this  point,  you  can  do  the  rest  of  the  display  loop  */ 

)    /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine...*/ 
dele  temachi  nepa  th(&remot  emachine 1 ) ; 
del e  temachi nepa th(&r emo  temachi ne2) ; 
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4.      prog2.c 

a.  Calling  Protocols 

This  is  a  test  program  for  the  broadcast  protocol.  By  command  line  argument, 
another  machine  to  receive  broadcast  messages  from  can  be  specified.  The  default  is  to 
receive  messages  from  irisl.  It  must  be  run  in  conjunction  with  prog.c  to  function 
properly,  as  the  port  assignments  are  hardcoded. 

b.  Code  and  Description 

/*  this  is  file  prog2.c 

It  is  a  sample  top  level  program  for  the  asynchronous  reading 
and  writing  of  sockets  via  shared  memory  and  two  other  processes. 

This  program  spawns  off  the  required  processes. 

This  program  uses  structure  type  Machine  declared  in  file  shared. h. 

*/ 

#include  "shared. h" 
#define  TRUE  1 

ma  in( argc , argv) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 


Machine  remot emachinel 
Machine  remot emachine2 
char  o ther_mach ine [50] 


/*  first  structure  for  remote  machine  */ 

/*  second  structure  for  remote  machine  */ 

/*  name  of  other  machine  */ 

char  mybuffer [LARGESTREAD] ;      /*  received  data  */ 

char  out  going [LARGESTREAD] ;      /*  outgoing  message's  buffer  */ 


int  mybufferl [LARGESTREAD/ INTEGER.SIZE] 
int  ou t go ingl [LARGESTREAD/ INTEGER^SIZE] 
float  mybuffer2[LARGESTREAD/FLOAT_SIZE] 
float  outgoing2[LARGESTREAD/FLOAT_SIZE] 


/*  received  integer  data  */ 

/*  outgoing  integer  message's  buffer  */ 

/*  received  float  data  */ 

/*  outgoing  float  message  buffer  */ 


long  noutgoing;  /*  size  of  the  outgoing  message  */ 

char  tempi  10];  /+  temp  array  used  to  make  outgoing  message  */ 

long  count  =  0;  /*  message  counter  */ 

char  rece i ved_t ype( ) ; 

char  type_rece i ved; 
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int  e lemen t s_rece i ved; 

long  i;  /*  temp  loop  variable  */ 

long  j  =  0;  /*  variable  to  control  message  sending  */ 

/*  pull  out  the  string  from  the  argument  list  */ 
i  f ( argc  >  2) 

I 

pr in t f ( "PROG2 :  incorrect  argument  count!   use  gprog2  <alias>\n"); 
exi t(l)  ; 

} 

/*  pull  out  the  name  of  the  other  string,  if  it  exists  */ 

if(  argc  ==  2  ) 

I 

strcpy(  ot her_machine ,  argvfl]  ); 

I 
else 

strcpy(  other_machine ,  "npscs - i r i s2"  ); 

/*  create  a  path  to  a  particular  machine  (iris2  default)  */ 
/*  the  first  argument  is  the  maximum  number  of  channels  to  be  created, 
the  second  argument  is  the  key  for  the  shared  memory  segment, 
the  third  argument  is  the  name  of  the  machine  to  connect  to. 
the  fourth  argument  is  the  sending  port  number  for  the  socket  to  use. 
the  fifth  argument  is  the  receiving  port  number  for  the  socket  to  use 
the  sixth  argument  indicates  whether  the  processes  should 
act  as  a  server  or  a  client, 
the  seventh  argument  is  the  returned  pointer  to  the  structure 

remot emachinel  or  remotemachine2 . 

it  includes  the  pointer  to  the  shared  memory  segment, 

the  system  generated  shared  memory  id,  the  sendsem  id, 

and  the  returned  receivesem  id. 

*/ 

dynami  emach i nepa  ths  (2,1,  o  t  he  r_mach  i  ne  ,3,4,  "receive"  ,&remot  emach  ine2  )  ; 

sleep(5);   /*  to  let  both  ends  of  the  process  get  set  up  */ 

dynamicmachi nepa ths (2,1 ,other_machine ,1,2, "broadcas  t " ,&remot emach ine  1 )  ; 

/*  the  display  loop  and  loop  for  polling  the  shared  segment  */ 
while (TRUE) 

I 

/*  make  an  outgoing  message  */ 
strcpy(outgoing, "PROG2  ORIGINATED  MESSAGE:  "); 

count  =  count  +  1; 

out goi ngl [0]  =  count; 

noutgoing  =  s t rlen(out going) ; 

outgoing2[0]  =  count; 

/*  is  there  data  in  the  shared  segment?  */ 
if(receiver_has_dat  a(&remot emach i  ne2 ) ) 

( 

1 ype_rece i ved  =  recei ved_t ype(&remot emachine2 ) ; 

print f ("The  message  received  by  PR0G2  is  of  type  %c    \n" , 
t ype_rece  i ved) ; 

switch  ( type_received) 
I 
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case  CHARACreR_ARRAY_TYPE : 

element s_received  =  numbc trece i ved(&remot emachine2 ) ; 

printf("The  message  received  by  PR0G2  is  %d   elements  long!\n", 
element  s_received); 

read_charac  t er s(&remot  emachine2  .mybuf fe  r , 
el  emen t s_recei ved) ; 
break ; 

case  INTEGERJTYPE : 

read_in t ege  r (Aremot  cmach  inc2 ,mybuf f erl ) ; 
break; 

case  FLQATTYPE: 

read_f loat (Aremot  emach i  ne2 , mybuf f er2) ; 
break; 

I 

/*  at  this  point  in  the  program,  process  the  received  data...*/ 
pr in t f ( "PROG2  has  received  the  following  data:\n"); 

switch  ( type_received) 

( 

case  CHARACreR_ARRAY_TYPE: 

for(i=0;     i    <    element s_recei ved ;     i+=l) 

I 

print f ("%c", mybuf fer[i J); 

break; 

case  INTEGER_TYPE : 

printf("%d"  .mybuf fer 1 [0] ) ; 
break; 

case  FLOAT_TYPE: 

print f("%f  " ,mybuffer2[0]); 
break; 


printf("\n" ); 


/*  at  this  point,  we  would  look  at  our  system  and  see  if  we  needed 
to  send  data.  Instead,  I  will  check  if  the  sender  is  free. 
If  the  sender  is  free,  I  will  send  one  of  three  messages  */ 

if(sender_i  s_f ree (Aremot  emach ine 1 ) ) 

I 
if((j  %  3)  ==  0) 

wr i te_charac ters  (Aremot  emach ine 1 ,ou t going ,nout going ) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 

while(  ! sender_i s_f ree (Aremot emach inel )  )  /*  do  nothing  pr in t f ( "2" )*/  ; 

if((j  %  3)  ==  1) 

wr  i  t  e_i  n t ege r  (Aremot  emach ine 1 .outgoingl) ; 

/*  wait  until  message  sent  before  attempting  to  send  another  */ 

while(  ! sender_i s_f ree(Aremot emachinel )  )  /*  do  nothing  prin t f ( "3"  )*/  ; 

if((j  %   3)  ==  2) 

wr  i  t  e_f loat  (Aremot  emach ine 1 ,out going2) ; 

/*  wait  until  message  sent  before  continuing  */ 

while(  ! sender_i s_f ree(Aremot emachinel )  )  /*  do  nothing  pr in t f ( "4" )* /  ; 

) 
else 
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/*  assume  socket  connection  broken  */ 
print f( "Sender  wasn't  free!   Tenninat ing. . . \n" ) 
break ; 


}    /*  endif  while  TRUE  */ 

/*  get  rid  of  the  path  to  the  other  machine 
de 1 e  temach  i nepa t h(&remot  emach  ine2)  ; 
de 1 e  t  emach  t  nepa  th  (&remot  emach inel ) ; 
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5.      rmshare.c 

a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  remove  all  shared  memory  segments  owned 
by  the  user.  By  command  line  argument,  selective  segments  can  be  removed. 

b.  Code  and  Description 


*      TITLE 

rmshare . c 


In ter -Computer    Communication    Package 


1.0 

25  February  1988 

Theodore  H.  Barrow 


*  NCDULE 

* 

*  VERSION 

* 

*  DATE 

* 

*  AUTHOR 

* 

*  HISTORY: 

*  VERSION 

*  DATE 


1.0 

25  February  1988 

Theodore  H.  Barrow 

Removes  shared  memory  segments  identified  on  command  line 


*  AUTHOR 

*  DESC. 

*  RECORD  OF  CHANGES 

* 

♦Version*   Date   *   Author  *  *   Affected    *Reqd 

*  *     Change  Description  *   Modules    *Vers 

*  *  *  *  *  ♦ 

*  *  *  * 
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#include  <errno.h> 

#include  <sy s/sy smacros . h> 

#include  <stdio.h> 

#include  <sy s / t ypes . h> 

#include  <sys/ipc.h> 

#include  <sys/shm.h> 

#i  nc lude  <gl . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE   IRIS4D 

#define  MACHINE   IRIS3000 

#endi  f 

extern  int  errno; 

ma  in(  argc  ,  argv  ) 

int  argc;        /*  argument  count  */ 

char  *argv[];    /*  pointers  to  the  passed  in  arguments  */ 

I 

int  first  =  1; 

int  last   =  1000; 

key_t  i ; 

int  shmid; 

key_t  key; 

static  struct  shmid_ds  buffer; 

/*  set  the  number  of  shared  memory  keys  to  remove  */ 
i  f ( argc  >  1 ) 

I 

for(  i=first;  i<argc;  i++  ) 

I 
key  =  atoi(  argv[i]  ); 

if(  (shmid  =  shmget(  key,  0,  0))  ==  -1  ) 

I 
if(  errno  !=  ENOENT  ) 

I 

write_error(  shmid,  key,  errno  ); 

) 

) 
else 

I 

if(  shmctl(  shmid,  IPC_RMID,  Abuffer  )  ==  - 1  ) 

( 
write_error(  shmid,  key,  errno  ) ; 

I 
e  1  se 

write_done(  shmid,  key  ); 
}   /*  if(  (shmid  =  shmget(  i ,  0,  0  ) )  ==  - 1  )  */ 
I   /•  for  */ 
} 
else 

I 

for(  i=first;  i  < 1  a  s  t ;  i++  ) 

I 

if(  (shmid  =  shmget(  i,  0,  0))  ==  -1  ) 

I 

if(  errno  !=  ENOENT  ) 
( 

write_error(  shmid,  i,  errno  ); 

} 
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) 

else 

I 

if(  shmctl(  shmid,  IPC_RMID,  Abuffer  )  ==  - 1  ) 

I 
write_error(  shmid,  i,  errno  ); 

} 
else 

write_done(  shmid,  i  ); 
}   /*  if(  (shmid  ■  shmget(  i,  0,  0  ))  ==  -1  )  */ 
}   /*  for  ♦/ 
I 

print f(  "\nComple ted . \n"  ); 
)   /*  main()  */ 

write_error(  shmid,  key,  error  ) 
int  shmid; 
key_t  key; 
int  error; 

( 

printf(  "\nShared  Memory  ID  %d  (key  %d)  caused  error  %d.", 
shmi  d,  key,  error  ); 

}   /*  wr  i  te_error( )  */ 

write_done(  shmid,  key  ) 
i  n t  shmid ; 
key_t  key; 

( 

print f(  "\nShared  Memory  ID  %d  (key  %d)  removed.",  shmid,  key  ); 

j   /*  wri  te_done( )  +/ 
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6.      testshare.c 

a.  Calling  Protocols 

This  is  a  stand-alone  utility.  It  will  print  current  parameters  for  all  active 
shared  memory  segments.  By  command  line  argument,  selective  segments  can  be 
printed. 

b.  Code  and  Description 


!++*+******+****************************************************************** 

*  * 

*  TITLE   :  In t er -Compu t er  Communication  Package  * 

*  * 

*  MXXJLE    :     testshare.c  * 

*  * 

*  VERSION:     1.0  * 

*  * 

*  DATE         :    25    February    1988  * 

*  * 

*  AUTHOR  :  Theodore  H.  Barrow  * 

*  * 
****************************************************************************** 

*>  * 

*  HISTORY:  * 

*  * 


*  VERSION 

* 

*  DATE 

+ 

*  AUTHOR 

*  DESC. 

* 


1.0 

25  February  1988 

Theodore  H.  Barrow 

Determines  which  shmid  values  are  used  and  what  their 
par  ame  t  e  r  s  are. 


****************************************************************************** 
*  RECORD  OF  CHANGES  * 


*  Affected    *Reqd* 

*  Modules    *Vers* 


♦Version*      Date      *     Author  * 

*  *  Change   Description 

****************************************************************************** 

*  *  *  *  *  *  * 

*  +  *  *  * 
*********** ******************************************************************^ 
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testshare.c 

#include  <errno.h> 

#include  <sy s / sy smac ros . h> 

^include  <stdio.h> 

#include  <sy s / t ype s . h> 

^include  <sys/ipc.h> 

^include  <sys/shni.h> 

#i  nc lude  <g 1  . h> 

/*  The  following  defines  will  have  to  be  modified  for  different  machines 
but  one  of  the  underlying  shared  memory  attachment  mechanisms  should 
work  for  any  system  V  implementation.  */ 

#define  IRIS4D    1 

#define  IRIS3000  2 

#ifdef  FLAT 

#define  MACHINE      IRIS4D 

IP  c  1  s  c 

#define  MACHINE   IRIS3000 

#endi  f 

extern  int  errno; 

ma  i  n (  ) 

I 

int  first  =  1 ; 

int  last   =  1000; 

int  i  ; 

int  8  hmi  d ; 

for(  i  =  first;  i< 1  as  t ;  i++  ) 

I 

if(  (shmid  =  shmget(  i,  0,  0))  ==  -1  ) 

I 
if(    errno    !=  ENOEOT   ) 

I 

write_error(  shmid,  i,  errno  ); 

} 
) 
else 

( 
if(  wr  i t e_s t rue t (  shmid  )  ==  - 1  ) 

write_error(  shmid,  i,  errno  ); 
)   /*  if(  (shmid  =  shmget(  i,  0,  0  ))  ==  -1  )  */ 
}   /*  for  */ 

printf(  "\nCompleted.\n"  ); 

}   /*  main()  */ 

write_error(  shmid,  key,  error  ) 
int  shmid ; 
key_t  key; 
int  error ; 

I 

printf(  "\nShared  Memory  ID  %d  (key  %d)    caused  error  %d . " , 
shmid,  key ,  error  ) ; 

)   /*  wr  i te_error ( )  */ 

struct  shmid_ds  *get_struct(  shmid  ) 
int  shmid ; 

I 

static  struct  shmid_ds  buffer; 

if(  shmctl(  shmid,  IPC_STAT,  Abuffer  )  ==  - 1  ) 

161 


testshare.c 


return(  (struct  shmid_ds  *)-l  ); 

I 

e  1  se 

return(  &buf f er  ) ; 

I   /*  get_struct()  ♦/ 


wr  i t e_s t rue t (  shmid  ) 
int  shmid; 


struct  shmid_ds  *buf; 

if(  (int)(buf  =  get_struct(  shmid  ))  ==  -1  ) 
re  t urn(  (int)buf  ); 


pr  int  f 
pr  int  f 
pr  in t  f 


Pr 


pr  in  t  f 


Pr 
Pr 
Pr 
pr 
Pr 


Pr 


Pr 
Pr 


ntf 


ntf 
ntf 
ntf 
ntf 
ntf 


print  f 


ntf 


pr  int  f 
pr  i  n  t  f 
pr  int  f 


ntf 
ntf 


pr  int  f 


return 


)   /*  wr  i 


"\nSha 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

"\n 

0  ); 


red  Memor 

shm_perm 

cuid  i 

cgid  i 

uid  is 

gid  is 

mode  i 

seq  is 

key  i  s 

s  hm_  s  e  g  s  z 

s  hm_  r  e  g  i 

s  hm_  1 p  i  d 

shm_cpid 

shm_nat  t  c 

shm_cnat  t 

shm_a  t  ime 

shm_dt  ime 

slim  c  t  ime 


y  ID  %d  h 
has  the  f 
s  %d .  "  ,  b 
s  %d . " ,  b 
bu 
bu 
b 
bu 
bu 
or 


%d .  "  , 
s  %o." 


%d."  , 

is  %d 

s  a  st rue 

is  %d.", 

is  %d.", 

h  i  s  %d  . " 

ch  i  s  %d  . 

is  %d  . " , 

is  %d."  , 

is  %d."  , 


as  the  following  structure:",  shmid  ); 

ol lowing  structure:"  ); 

uf ->shm_perm. cuid  ); 

uf ->shm_perm.  cgid  ); 

f ->shm_perm.  u id  ); 

f ->shm_perm. gid  ); 

uf  ->shm_perm.mode  ); 

f - >  s hm_pe  rm . s  e q  ) ; 

f ->shm_perm.key  ); 

%x  .  "  ,  buf ->shm_segsz ,  buf ->shm_segsz  ); 
ture  incompletely  defined  in  region. h!"  ) 
buf ->shm_lpid  ) ; 
buf ->shm_cpid  ); 
,  buf ->shm_na t tch  ); 
",  buf ->shm_cnat tch  ); 

buf ->shm_a t ime  ) 

buf ->shm_dt  ime  ) 

buf ->shm_segsz  ) 


e_s  t  rue  t ( )  */ 
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